AD  A119998 


AEVJAL-TR-82--2058 


TURBINE  ENGINE  FAULT  DETECTICN  AND  ISOLATION  PROGRAM 
VOLUME  I  -  Turbine  Engine  Performance  Estimation  Methods 


SYSTEMS  CONTROL  TECHNOLOGY,  INC. 
1801  Page  Mill  Read 
Palo  Alto,  CA  94303 


AUGUST  1982 


AERO  PROPULSION  LABORATORY 
AIR  FORCE  WRIGHT  AERONAUTICAL  LABORATORIES 
AIR  FORCE  SYSTEMS  COMMAND 
WRIGHT-PATIERSCN  AIR  FORCE  BASE,  OHIO  45433 


32  10  07  02Z 


NOTICE 


When  government  drawings,  specifications,  or  other  data  are  used  for  any 
purpose  other  than  in  connection  with  a  definitely  related  government  procure¬ 
ment  operation,  the  United  States  Government  thereby  incurs  no  responsibility 
nor  any  obligation  whatsoever;  and  the  fact  that  the  government  may  have  for¬ 
mulated,  furnished,  or  in  any  way  supplied  the  said  drawings,  specifications, 
or  other  data,  is  not  to  be  regarded  by  implication  or  otherwise  as  in  any 
manner  licensing  the  holder  or  any  other  person  or  corporation,  or  conveying 
any  rights  or  permission  to  manufacture,  use,  or  sell  any  patented  invention 
that  may  in  any  way  be  related  thereto. 

This  report  has  been  reviewed  by  the  Office  of  Public  Affairs  (ASD/PA) 
and  is  releasable  to  the  National  Technical  Information  Service  (NTIS).  At 
NTIS,  it  will  be  available  to  the  general  public,  including  foreign  nations. 

This  technical  report  has  been  reviewed  and  is  approved  for  publication. 

CHARLES  A.  SKIRA  LESTER  L.  SMALL,  TAM 

Project  Engineer  Controls  Technology 

FOR  THE  COMMANDER 


^'lAurr  u  niTm/Aii  u. 


JAMES  M.  SHIPMAN,  Major,  USA^ 
Deputy  Director 
Turbine  Engine  Division 


If  your  address  has  changed,  if  you  wish  to  be  removed  from  our  mailing 
list,  or  if  the  addressee  is  no  longer  employed  by  your  organization,  please 
notify  AFWAL/POTC,  W-PAFB,  Ohio  45433  to  help  us  maintain  a  current  mailing 
list. 

Copies  of  this  report  should  not  be  returned  unless  return  is  required  by 
security  considerations,  contractual  obligations,  or  notice  on  a  specific 
document. 


UNCLASSIFIED _ _ 

security  classification  of  this  rage  rw»««  Data  nnr^)  _ _ 

REPORT  DOCUMENTATION  PAGE  beforIPcompletSg^form 

T^i^o'Af'NUMlfS"” -  -  III  GOVT  ACCEUlON~oI  1.  RECIRIEnT'SCATALOCI  NUMBER 

AFWAL-TR-82-2058,  Volume  I  fh . 

4.  TITLE  (*n4  ‘sukttttm)  »•  '**m00  C0'/t*tD 

TURBINE  ENGINE  FAULT  DETECTION  AND  August  1979  -  November  1981 

ISOLATION  PROGRAM  :  Turbine  Engine  Performance! . ytR7'oRMiNooRo.  »eroVt  nLm'beS — 

Estimation  Methods 


7,  AU tHOUfej - - - - -  f.  CONTRACT  O*  OAAMT  NUMlCFK’O 

Ms.  Carolyn  Smith,  Mr.  Mark  Broadie,  F33615-78-C-2062 

Dr.  Ronald  DeHoff 

VRERFO,rM7NO  ORGANIZATION” NAME  ANO  ADDRESS  ,0'  ISS2" ^oWuSitVumm'm'  T 

SYSTEMS  CONTROL  TECHNOLOGY,  INC.  ,n<.,,,97 

1801  Page  Mill  Road  30661327 

_ Pain  Alto..fA-3fl3Q3 - -  ~  ■— - 

II.  CONTROLLING  office  NAMK  AMO  aooress  /IHK8SI  °f§o2 

AERO  PROPULSION  LABORATORY  (AFWAL/POTC)  - - ^  —  -  ... - 

Air  Force  Wright  Aeronautical  Laboratories  ’*■  240"  "°  A0 
Wriqht.-Pat.t.prlnn  AFR.  DM  AS43? _ ill - 

TV  MONITORING  AGENCY  NAMK  *  AOORESS/’lf FMml  trmm  Camatalllng  Qtttaa)  'S.  SECURITY  CLASS.  (at  Uila  tatatt) 


10.  RROORAM  ELEMENT.  RROJECT,  TASK 
AREA  0  WORK  UNIT  NUMBERS 


30661327 


“■Kiiii6 m 


II.  NUMBER  OF  RASES 

240 


UNCLASSIFIED 


la.  declassification/ downgrading 
SCHEDULE 


14.  DISTRIBUTION  STATEMENT  (at  thla  R«ji art) 


Approved  for  public  release;  distribution  unlimited. 


17.  DISTRIBUTION  STATEMENT  (at  tha  aAatraat  ant  trad  In  Blank  20,  It  dtttarant  tram  Raoatt) 


is.  surflcmentary  notes 

This  report  consists  of  two  volumes:  Volume  II  -  Maintenance  Model 
Development  Report 


19.  KEY  WORDS  (Canttma  an  rararta  a/da  It  naaaaaarr  and  tdanllty  hr  Uoek  tnaaktr) 

IECMS ,  TEMS,  EDS,  MIMS,  ECM,  TEFDI,  TF34,  TF41 ,  F100 


20.  ABSTRACT  (Continue  an  tereree  iltfi*  H  n«oe«t«y  m4  Identity  by  block  number) 

^This  report  documents  work  done  for  the  Turbine  Engine  Fault  Detection 
and  Isolation  Program.  A  gas  path  performance  algorithm  has  been  developed 
which  can  be  used  to  trend  engine  module  health.  The  Maintenance  Informa¬ 
tion  Management  System  was  developed  for  the  integration  of  data  into  the 
maintenance  framework  of  the  services.  These  tools  have  been  applied  to 
test  data  from  the  FI  00/EDS •  TF34/TEMS  and  TF41/IECMS  data  acqu  isition 
sys  terns 


DD  ,  'jT-n  1473 


EDITION  OF  I  NOV  SS  IS  OBSOLETE 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  THIS  R AGE  flWiM  Data  Entarad) 


TABLE  OF  CONTENTS 


Page 


I.  EXECUTIVE  SUMMARY  .  1 

1.1  Introduction  .  1 

1.2  Summary . . . . . .  2 

II.  TURBINE  ENGINE  PERFORMANCE  MONITORING  .  4 

2.1  Introduction  .  4 

2.2  The  Thermodynamic  Performance  Monitoring  Problem  .  14 

2.2.1  Data  Acquisition  Requirements  .  14 

2.2.2  Engine  Modeling  Approaches  . . .  17 

2.2.3  Approaches  to  Measurement  Processing  .  28 

2.3  Practical  Aspects  of  Cycle  Monitoring  Algorithms  .  29 

2.3.1  Three  Areas  of  Practical  Concern  . .  30 

2.3.2  Thermodynamic  Cycle  Monitoring  Methodology  .  31 

2.4  Summary .  31 

III.  MATHEMATICAL  FOUNDATIONS  OF  THERMODYNAMIC  CYCLE  MONITORING  .  34 

3.1  Introduction  .  34 

3.2  Modeling  .  34 

3.3  Parameterization  .  43 

3.4  Sensor  Validation  .  57 

3.5  Estimation  . 66 

3.6  Trending  . 74 

/ 

IV.  INTEGRATION  WITH  MAINTENANCE  MANAGEMENT  .  89 

4.1  Introduction  . 89 

4.2  Requirements  Background  .  90 

4.2.1  Management  Organization  . .  90 

4.2.2  Engine  Maintenance  Philosophy  .  93 

4.2.3  User  Requirements  for  Monitored  Propulsion  Data  ....  98 

4.3  Functional  Descriptions  vs.  Requirements  Definition  .  102 

4.4  Data  Item  Interface  Recommendation  .  105 

4.4.1  TEMS  Implementation  Requirements  .  110 

4.4.2  Base  Computer  . . 113 

4.4.3  Shop  Record  Information  .  113 

4.4.4  Depot/Central  Data  Items  .  114 

4.4.5  Summary  of  Data  Items  and  Interface  Recommend¬ 
ations  . 114 


TABLE  OF  CONTENTS  (Continued) 


Page 


4.5  Base  Processor  Configuration  Options  .  116 

4.6  Software  Requirements  .  119 

4.6.1  Architecture  of  the  Operating  System  .  122 

4.6.2  Applications  Software  .  122 

4.7  Maintenance  Information  Management  System  .  124 

V.  APPLICATION  TO  A10/TF34  TEMS  Flight  Service  Evaluation  Data  ....  127 

5.1  Introduction .  127 

5.2  Test  Background .  127 

5.3  Thermodynamic  Cycle  Monitoring  Algorithm  Development  .  134 

5.3.1  Data  Screening  .  135 

5.3.2  Model  Development .  135 

5.3.3  Lumped  Parameters  -  Module  Indices  .  149 

5.1  Highlights  of  Results .  153 

VI.  APPLICATION  TO  F15/F100  EDS  FLIGHT  TEST  DATA .  167 

6.1  Introduction . 167 

6.2  Test  Background  . 167 

6.3  Model  Developments  .  174 

6.4  High-Power/ Low-Power  Analyses  .  179 

6.5  Cluster  Analysis  .  182 

6.6  Pilot  Option/Automatic  Take-Off  Record  Analysis  . . .  182 

6.7  Final  Baseline  Model  Development,  Parameterization,  and 

Highlights  of  Results  .  193 

VII.  APPLICATION  TO  A7E/TF41  IECMS  DEPLOYMENT  DATA  .  203 

7.1  Introduction  . 203 

7.2  Test  Background .  203 

7.3  IECMS  Description  .  203 

7.4  Data  Inspection . 205 

7.5  Cluster  Analysis  and  Data  Screening  .  205 

7.6  Baseline  and  Fault  Model  Development  .  209 

7.7  Module-Directed  Rating  Parameters /Performance  Algorithm 

Results  .  221 

VIII.  SUMMARY  AND  CONCLUSIONS  .  235 

REFERENCES  .  237 


1v 


LIST  OF  TABLES  (Continued) 

Page 


4.1  Typical  Maintenance  Decisions/Scenarios  by  User  Level  .  S9 

4.2  Troubleshooting  Information  Requirements  .  100 

4.3  Preventive  Maintenance  Information  Requirements  .  101 

4.4  Logistics  Management  Decision  Scenarios  at  Depot  and  Command 

Level  .  103 

4.5  Information  to  Support  Typical  Command  Level  Engine  Management  104 

4.6  Relationship  Between  Functional  Definition  and  System 

Requirements  .  106 

4.7  Survey-Determined  Required  Data  Items  (Source/Documentation)  107 

4.8  Data  Source  Subsystems  .  109 

4.9  Sensor  Requirements  vs.  Capability  for  Automated  TEMS  .  Ill 

4.10  Data  Item  and  Interface  for  Integrated  System .  115 

4.11  A  Comparison  of  Operating  Executive  and  Application  Functions  123 

4.12  Software  Functional  Description  Application  Modules  .  126 

5.1  Summary  of  A10/TF34  Test  Flight  Evaluation  .  129 

5.2  Categorical  Analysis  per  Test  Plan  1  November  through 

31  October  1979  .  133 

5.3  A10  TEMS  Data  Acquisition  Windows  .  136 

5.4  Final  Data  Selection  Criteria  . .  139 

5.5  Baseline  Model  Accuracy  .  141 

5.6  Fault  Parameter  Definitions  . 150 

5.7  Performance  Model  .  151 

5.8  TF34/TEMS  Identif iabi 1 ity  .  152 


vi 


i 


LIST  OF  TABLES  (Concluded) 


.  Page 


6.1  EDS  Flight  Evaluation  Phase  .  168 

6.2  EDS  Aircraft  Flight  Statistics  . . .  170 

6.3  EDS  Engine  Flight  Statistics . . .  171 

6.4  Record  Transmittal  Summary  by  Engine  Serial  Number  .  175 

6.5  Variable  Means  .  176 

6.6  Model  Standard  Deviations  . .  177 

6.7  F100  Model  Standard  Deviations  . 178 

6.8  Data  Repeatability  Results:  Low  vs.  High  Power  Data  .  181 

6.9  EDS  Data  Acquisition  Results  .  183 

6.10  Data  Repeatability  Results:  Low  vs.  High  Power  Data  .  184 

6.11  Sample  Cluster  Analysis  Results  .  186 

6.12  Statistical  Summary  of  EDS  Data  Base  . .  191 

6.13  Statistical  Summary  of  EDS  Pilot  Option  .  192 

6.14  Comparison  of  Model  Standard  Deviations  Data  Set  Number  .  194 

6.15  EDS  Data  Screening  Limits . 195 

6.16  F100  Baseline  Model,  June  1980  . 196 

7.1  Maximum  and  Minimum  Values  of  Data  Sets  .  210 

7.2  IECMS  Data  Screening  Limits  . . 216 

7.3  IECMS  Baseline  Model  Statistical  Summaries  .  217 

7.4  Flight  Conditions  for  Fault  Model  Data  Base  .  222 

7.5  Fault  Parameter  Definitions  and  Perturbations  .  223 


vii 


\ 

i 

\ 

i 

■I 

* 

i 

i 

i 

] 

i 

3 

j 

'i 

k 

i 

i 

■j 

A 


LIST  OF  ILLUSTRATIONS 


2.1  Comprehensive  Performance  Monitoring  Aspects  . 

2.2  Engine  Diagnostic  View  of  Data  Processing  Scenario  * . 

2.3  Comparison  of  Two  Approaches  to  Classical  Performance  Analysis 

2.4  Processing  Flow  for  Engine  Performance  Diagnostics  Using 

Automated  TEMS  . 

2.5  Corrected  Baseline  Model  . . . 

2.6  Levels  of  Modeling  Detail  . 

2.7  Linear  Performance  Analysis  . 

2.8  Development  of  Advanced  Monitoring  Algorithms  . 

3.1  Graphical  Illustration  of  the  Engine  Model  . 

3.2  Model  Complexity  Versus  Model  Accuracy  . 

3.3  Screened  Data  with  Baseline  Model  . 

3.4  Residual  Plot  with  Average  Fit  Error  . 

3.5  A  Typical  Baseline  Model  . . 

3.6  Computer  Representation  of  QLR  Model  . . 

3.7  Fault  Model  Development . . . . 

3.8  Model  Generation  Procedure  . 

3.0  A  Typical  QLR  Model  . 

3.10  Module-Directed  Performance  Example  . 

3.11  Module-Directed  Performance  Parameters  . 

3.12  Parameter  Projection  Decomposition  . . 

3.13  General  Cross-Validation  Processing  Flow  . 

3.14  Performance  Estimation  Flowpath  . 

3.15  Off-Line  Processing  Scenario  . . 


LIST  OF  ILLUSTRATIONS  (Continued) 


Page 

3.16  Trending  Routine  Example  . ; .  76 

3.17  Trending  Example .  77 

3.18  Trending  Example .  78 

3.19  Trending  Example  .  80 

3.20  Trending  Example . 81 

3.21  Flowchart  for  the  Trending  Routine  .  84 

3.22  Sample  Trending  Routine  Result:  Data  with  a  Gap  in  X  Values  ..  85 

3.23  Sample  Trending  Routine  Result:  Data  with  Three  Jumps  .  86 

3.24  Sample  Trending  Result  .  87 

3.25  Sample  Trending  Result  .  88 

4.1  Driving  Elements  for  the  Development  of  an  Integrated  Engine 

Monitoring  Capability . 91 

4.2  Air  Force  Engine  Management  Echelon  .  92 

4.3  Integrated  Maintenance/Logistics  Network  .  94 

4.4  Development  Process  for  an  RCM  Plan  .  97 

4.5  Local/Global  Interface  .  117 

4.6  Base  Central  Computer  Configuration  to  Support  Automated  TEMS- 

Acquired  Data  . 118 

4.7  Distributed  Base  Architecture  Supporting  Automated  TEMS- 

Aquired  Data . . .  120 

4.8  Complete  Base  Level  Distributed  Processing  Scenario  .  121 

4.9  Software  Modularity  in  Engine  Monitoring  and  Trend  System  .  125 

5.1  TEMS  Hardware  Configuration  .  130 

5.2  TEMS  Detected  Event  Summary . . . v .  132 

5.3  Raw  TEMS  Stabilized  Scans  .  137 

ix 


LIST  OF  ILLUSTRATIONS  (Continued) 


Page 

5.4  TF34/TFMS  Screened  Data  Scans . . .  138 

5.5  Residual  Plot  for  PS3  Model  -  All  Engines  .  142 

5.6  PT5  Model  Residual  Showing  Effect  of  Failed  Sensors  .  144 

5.7  Soft  PLA  Failures  .  146 

5.8  Plots  Showing  ITT  Sensor  Faults  . . 147 

5.9  Health  Indices  for  E5226  . . 154 

5.10  Health  Indices  for  £5237  .  157 

5.11  Short-  vs.  Long-Term  Trends  .  159 

5.12  Net  Engine  Rating  with  Maintenance  Correlation  .  163 

6.1  EDS  Data  Collection  . 173 

6.2  Histogram  of  EDS  Points  vs.  PLA  Range  .  180 

6.3  Cluster  Algorithm  Flowchart  . 185 

6.4  Sample  Pilot  Option  Scans:  T25C  .  188 

6.5  Delta  T25C:  50  Scans  .  189 

6.6  Delta  T25C:  Mean  and  Cl  .  190 

6.7  High  Power  EDS  Data  E0694:  Residual  WF  .  197 

6.8  High  Power  EDS  Data  E0694:  Residual  N2  .  199 

6.9  F100  Module-Directed  Indices  . 201 

6.10  F100  Performance  Rating  Histories  . .  202 

7.1  E1614  Take-Off  Data:  Oul'i  vs.  TOT . . .  206 

7.2  E2553  Take-Off  Data:  Juli  vs.  TOT . 207 

7.3  E1243  Take-Off  Data:  Juli  vs.  TOT .  208 

7.4  Take-Off  D<ita  Distribution  Plot  .  213 

7.5  Cruise  Data  Distribution  Plot .  214 


x 


LIST  OF  ILLUSTRATIONS  (Concluded) 


Page 

7.6  Combined  Data  Set  Distribution  Plot  .  215 

7.7  IECMS  Take-Off  Data . 218 

7.8  IECMS  Cruise  Data  (E2553)  .  219 

7.9  IECMS  Cruise  Data  (E1226)  . 220 

7.10  E2553:  Residual  T3 .  228 

7.11  Vibration  History  for  E2553  .  226 

7.12  Low  Spool  Rating  for  E1930  (Mode  2000)  .  227 

7.13  Compressor  Rating  for  E1930  (Mode  2000)  . .  228 

7.14  Residual  NL  for  E1930  .  229 

7.15  Low  Spool  Rating  for  £2553  (Mode  2000)  . .  230 

7.16  High  Pass  Turbine  Rating  -  Cruise  Mode  Data  .  231 

7.17  High  Pass  Turbine  Rating  -  Take-Off  Mode  Data .  232 

7.18  Low  Spool  Rating  -  Cruise  Mode  Data  . .  233 

7.19  Low  Spool  Rating  -  Take-Off  Mode  Data . 234 


xi 


iuW'iiwiu JrtJjU'kiLu*'* ;;ka*  'jilLJ  ^ii'v  zu.xi t  j-  ...  - ../■ 


..tin 


I.  EXECUTIVE  SUMMARY 


1.1  INTRODUCTION 

High  performance  aircraft  used  in  modern  military  service  are  complex  in 
design,  operate  under  severe  levels  of  stress  and  temperature,  and  undergo 
frequent  operational  cycles.  Consequently,  identification  of  component 
degradations  and  failures  is  difficult.  Additionally,  inflation  and  the  high 
cost  of  engines  and  spare  parts  has  brought  considerable  pressure  upon  the 
services  to  search  for  effective  ways  to  maintain  and  manage  these 
high-performance  propulsion  systems.  Maintenance  based  upon  monitoring  engine 
condition  rather  than  at  specific  predetermined  Intervals  has  become  the 
ultimate  goal. 

As  a  means  to  attaining  this  goal,  a  number  of  turbine  engine  monitoring 
systems  have  been  and  are  now  being  developed  and  tested  for  possible 
adaptations  to  in-service  aircraft.  What  has  been  lacking  in  these  programs 
is  a  means  by  which  this  automated  data  can  be  integrated  into  the  framework 
of  the  Air  Force  maintenance  management  organization.  Activities  of  the 
Turbine  Engine  Fault  Detection  and  Isolation  Program  attempt  to  address  this 
problem.  The  goal  of  the  program  is  the  development  of  a  data  processing 
procedure  which  is  sensitive  to  the  attributes  of  Flight-acquired  engine  data 
and  produces  output  which  can  be  used  by  maintenance  personnel  to  support  the 
propulsion  plant. 

This  report,  documents  the  results  of  a  three-phase  program  which 
sequentially  presents  solutions  to  several  issues  associated  with  the  use  of 
performance  estimation  and  automated  data  acquisition  systems  within  an 
integro.e'J  engine  monitoring  program.  The  key  questions  are: 

(1)  Can  engine  performance  ratings  derived  from  automated  data  be 
integrated  into  the  Air  Force  maintenance/  logistics 
organization  and  interface  with  existing  multi-echelon 
information  systems  supporting  engine  management? 

(2)  Can  a  performance  estimation  algorithm  be  developed  to 
accurately  process  automated  data  to  satisfy  fault  detection, 
isolation  and  trending  requirements? 
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(3)  Can  an  integrated  engine  ".onitoring  system,  supported  by 

automatical ly  acquired  data;  support  operational  maintenance 
requirements 

Ultimately,  solutions  to  these  problems  will  provide  a  promising 
foundation  for  successful  integration  of  modern  data  processing  and  management 
methods  into  the  diagnostic  and  maintenance  operations  for  the  modern  armed 
services. 

1.2  SUMMARY 

This  report  is  organized  as  follows: 

•  Chapter  II:  Introduction  to  Engine  Performance  Monitoring 

This  chapter  reviews  the  fundamental  aspects  of  the  engine  performance 
monitoring  problem.  Existing  approaches  to  monitoring  and  gas  path  analysis 
are  discussed.  Practical  aspects  of  implementing  a  problem  solution  are 
presented  as  design  drivers  for  the  chosen  theoretical  algorithm. 

•  Chapter  III:  Mathematical  Methods  of  Thermodynamic  Cycle  Monitoring 

The  evolution  of  a  generic  methodology  that  is  applicable  over  a  wide 
class  of  engine  instrumentation  and  hardware  configurations  is  presented.  In 
this  chapter,  the  general  problem  is  formulated  and  the  thermodynamic  cycle 
monitoring  algorithm  is  developed. 

•  Chapter  IV:  Integration  With  Maintenance  Management 

This  chapter  presents  the  results  of  Phase  1,  during  which 
requirements  for  the  integration  of  performance  monitoring  into  the  Air  Force 
engine  management  process  were  formulated.  The  Air  Force  engine  management 
organization  is  described  and  the  reliability  centered  maintenance  philosophy 
is  discussed.  Functional  requirements  are  outlined  and  keyed  to  specific 
software  specifications. 
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•  Chapter  V:  Application  to  A10/TF34  TEMS  Flight  Service  Evaluation 

Data 

Chapter  V  examines  the  concept  of  an  integrated  engine  monitoring 
system  within  the  framework  of  the  A10/TF34  TEMS  flight  service  evaluation. 
Test  background  is  presented  along  with  developments  corresponding  to  the 
implementation  of  the  thermodynamic  cycle  monitoring  algorithm.  Results  are 
highlighted  and  potential  Impacts  of  the  system  are  presented. 

•  Chapter  VI:  Application  to  F15/F100  EDS  Flight  Test  Data 

Chapter  VI  discusses  the  experiences  of  the  F15/F100  EDS  flight  test 
data  evaluation.  Focus  is  on  the  improvement  of  data  acquisition  and 
processing  methods  which  are  employed  prior  to  analysis  in  the  thermodynamic 
cycle  monitoring  algorithm. 

•  Chapter  VII:  Application  to  A7/TF41  IECMS  Deployment 

Chapter  VII  discusses  application  of  the  principles  of  thermodynamic 
cycle  monitoring  to  IECMS  deployment  data.  Test  background,  data  analysis, 
and  results  are  presented. 


•  Chapter  VIII:  Conclusions 

This  chapter  summarizes  the  conclusions  of  the  TEFDI  program 
activities.  Impacts  achievable  with  the  development  and  implementation  of  an 
integrated  engine  monitoring  capability  are  Identified.  Based  on  the 
conclusions  of  .  program,  recommendations  are  made  for  areas  which  deserve 
further  investigation. 


II.  TURBINE  ENGINE  PERFORMANCE  MONITORING 


Determination  of  engine  health  indices  is  the  goal  of  performance 
monitoring.  Health  indices  (see  Table  2.1)  include  operating  time,  vibration, 
oil  contaiment  level,  particulate  size  distribution,  fatigue  cycles,  time  at 
temperature,  life  usage  factors,  thermodynamic  efficiency,  and  performance. 

An  effective  monitoring  procedure  allows  the  user  systematically  to  examine, 
plot,  trend,  and  analyze  indices  both  singly  and  in  conjunction  with  others. 

A  system  which  supports  comprehensive  engine  monitoring  within  a  tactical 
environment  (see  Figure  2.1)  is  the  goal  of  the  TEFDI  program.  This  chapter 
reviews  the  fundamental  aspects  of  the  problem  and  discusses  the  framework  for 
system  design. 

2.1  INTRODUCTION 

Engine  monitoring  schemes  have  been  devised  to  process  recorded  operating 
parameters  and  diagnose  engine  failures  at  the  flight  line.  Additional 
processing  is  required  to  track  engine  deterioration  and  aging.  After  many 
years  of  feasibility  testing  and  hardware  development,  the  Air  Force  is 
installing  on-board  monitoring  on  a  portion  of  the  tactical  inventory  [1]. 

The  data  utilization  scenario  often  used  for  this  type  of  hardware  is 
represented  in  Figure  2.2  [2].  Manufacturer-defined  limits  and  exception 
criteria  are  used  to  trim  and  troubleshoot  the  engine.  Normal  operating  data 
are  passed  to  a  central  data  bank  for  processing.  Advanced  monitoring 
procedures  can  provide  a  timely  capability  to  integrate  performance  and  usage 
data  for  display  and  utilization  by  management  personnel. 

Before  the  attributes  of  several  health  monitoring  approaches  are 
considered,  the  spectrum  of  engine  symptoms  and  diagnoses  will  be  examined. 
Table  2.2  lists  a  representative  sample  of  engine  faults,  and  procedures 
useful  for  detecting  them.  On-board  data  systems  typically  check  parameter 
exceedances  and  indicate  ground  inspection  activity.  More  sophisticated 
modeling  and  processing  of  accumulated  data  can  produce  subtle  inferences 


Table  2.1 


Engine  Health  Indices 


LOW  CYCLE  FATIGUE  (LCF) 

CUMULATIVELY  INDUCED  PLASTIC  STRAIN  DAMAGES 
LCF  EVENT  COUNTER  IMPLEMENTATION 

USAGE  FIGURES  REPRESENT  POPULATION-AVERAGED  RESULTS  RATHER  THAN 
ENGINE-PARTICULAR 

SPECTROGRAPHIC  OIL  ANALYSIS  (SOAP) 

ANALYSIS  OF  ENGINE  WEAR  PRODUCTS 

DETECTION  OF  NORMAL  WEAR  CONTENT 

COMPLEXITY/TURNAROUND  DELAY  ARE  PROBLEMS 

EVENT/EXCEEDANCE  DETECTION 

COMPATIBLE  WITH  REAL-TIME  DIAGNOSTICS 

EXCELLENT  FOR  TROUBLESHOOTING  HARD  FAILURES 

DOES  NOT  PRODUCE  PROGNOSTICATE  INFORMATION 

ENGINE  PERFORMANCE  MONITORING 

PRODUCES  ENGINE  PERFORMANCE  “STATE- 

TRENDING  AND  PROGNOSTICATION  ARE  FEASIBLE 

OFF-LINE  APPROACH 

ACCURACY  AND  RELIABILITY  TO  BE  ESTABLISHED 
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Figure  2.1  Comprehensive  Performance  Monitoring  Aspects 


concerning  engine  condition.  Central  data  processing  can  examine  and 
aggregate  trend  data  from  many  engines. 

Until  recently,  comnerclal  airline  approaches  to  performance  analysis 
have  concentrated  on  manual  recording  and  plotting  methods.  Uninstalled 
monitoring  methods  popular  with  engine  manufacturers  differ  from  the  installed 
approach  which  has  been  used  by  alrfrawe  manufacturers  and  operators.  Table 
2.3  lists  the  attributes  of  the  manual  system.  The  uninstalled  method  (Figure 
2.3)  examines  operating  line  shifts  due  to  deterioration  and  the  effect  of 
control  and  tr.m  actions  to  counteract  this  effect.  In  the  Installed 
approach,  deviations  from  a  point  (e.g.,  take-:ff  power  or  stabilized  cruise) 
are  recorded  and  trended  against  owner's  manual  levels  or  previous  baselines. 
Both  of  these  approaches  do  not  yield  direct  information  concerning  component 
health  levels. 

There  is  a  distinct  difference  between  the  requirements  and  capabilities 
of  a  diagnostic  system  and  a  trending  a.-alysis  system.  Trending  and 
diagnostic  system  attributes  are  compared  in  Table  2.4. 

Engine  diagnostic  systems  use  in-flight  or  flight-line-  acquired 
measurements  to  determine, discrete  failure  events  in  the  installed  engine. 

The  Air  Force  and  Navy  are  currently  evaluating  such  on-board  systems. 

Trending  analysis  systems  process  data  recorded  by  engine  monitoring  systems 
to  determine  the  deterioration  states  of  the  engine.  Deterioration  is  defined 
as  a  slow  degradation  of  performance  due  to  a  variety  of  microscopic  effects. 
Trending  analysis  has  the  potential  for  extracting  a  large  amount  of  engine 
performance  information  from  data  which  would  otherwise  be  discarded. 

Efficient  processing  of  these  data  (see  Figure  2.4)  can  produce  beneficial 
maintenance  indicators  and  when  integrated  with  current  usage  factors  (e.g., 
cycle  counts,  hot  time,  and  oil  analysis),  can  improve  logistics  practices  as 
part  of  a  comprehensive  engine  management  system. 

Analysis  of  current  engine  monitoring  techniques  and  the  capability  of 
demonstrated  data  acquisition  hardware  lead  to  a  number  of  significant 
conclusions  [3]  concerning  the  development  and  integration  of  an  automated 
diagnostic  procedure.  Some  of  these  are  summarized  below  (also,  see  Refs.  4 
through  6) . 


Table  2.3 


Traditional  Monitoring  Methods 

ROUTINELY  RECORD  AND  ANALYZE  STABILIZED  IN-FLIGHT  DATA 

COWARE  PERFORMANCE  OF  INDIVIDUAL  ENGINES  TO  OPERATIONS  MANUAL  OR  TO 
THE  REST  OF  THE  FLEET 

PLOT  RESULTS  VERSUS  TIME  OR  PERCENT  OF  DESIGN  THRUST 
TYPICALLY  10  POINTS  PER  MONTH  PER  ENGINE 


A 
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CORRECTED  TURBINE  PRESSURE 

%TSFC  temperature  ratio 


uninstalled  approach 


installed  approach 


[A _ 

OPERATING 

MANUAL 

ENGINE  DIAGNOSTICS 

TREND  ANALYSIS 

REAL-TIME  PROCESSING 

OFF-LINE  PROCESSING 

IN-FLIGHT/FLIGHTLINE/CALL 

BASE /DEPOT  LEVEL 

DISCRETE  EVENTS 

CONTINUOUS  PARAMETER  CHANGES 

DISCRETE  OUTPUTS 

STATISTICAL  OUTPUTS 

USES  PRIMARILY  EXCEPTION  RECORDING/ 
EXCEEDANCES 

PROCESSES  ALL  DATA  AND  EXTRACTS 
INFORMATION 

MICROPROCESSOR 

MINI /MACRO  COMPUTER 

ISOLATES  PARTICULAR  FAILURE  MODES, 

E.G.,  SEAL  FAILURE 

GIVES  MODULE-DIRECTED  DETERIOR¬ 
ATION  INFORMATION 

SENSOR  FAILURE  ISOLATION 

SENSOR  FAILURE  ISOLATION 

PERFORMANCE  WITHIN  BOUNDS 

CHECKING 

ACCURATE  PERFORMANCE  SHIFT 
CALCULATION 

CONTROL  ENGINE  FAILURE 

TRIM  HEALTH  ALERT 


ON-BOARD 


OFF-BCARD 


Figure  2.4  Processing  Flow  for  Engine  Performance  Diag¬ 
nostics  Using  Automated  TEMS 
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(1)  Integration  of  the  most  used  engine  usage  factors,  e.g.,  total 
operating  time,  low-cycle  fatigue  (LCF)  counts,  and  oil 
analysis  into  operation  is  primarily  a  data  management  end 
display  problem  [7]. 

(2)  Gas  path  analysis  and  perfor  nee  trending  have  been  initially 
demonstrated  in  a  diagnostic  or  fault  detection  mode.  The 
technique  Is  not  now  used  at  the  base  or  depot  Invel.  This  is 
due  primarily  to  the  difficulty  in  formulating  outputs  in  an 
easily  interprecable  format. 

(3)  Gas  path  analysis  can  be  integrated  into  maintenance  operations 
in  a  consistent  manner  with  other  usage  factors  [lj. 


2.2  THE  THERMODYNAMIC  PERFORMANCE  MONITORING  PROBLEM 


Engine  performance  monitoring  can  be  conceptualized  as  a  three-stage 
procedure.  First,  engine  operating  variables  such  as  rotor  speed,  pressure, 
and  temperature- are  recorded.  Then,  values  are  compared  with  operating  po'nt 
variations  (e.g.,  power  level  and  ambient  conditions)  and  variations  caused  by 
engine  deterioration  or  failure.  Finally,  these  comparisons  are  used  to  infer 
probable  causative  agents.  Twu  approaches  which  will  be  discussed  below  are 
shown  in  Table  2.5.  A  complete  engine  health  monitoring  methodology  must 
consider  each  stage  relative  to  the  accuracy  and  suitability  of  the  final 
result. 


2*2.1  Data  Acquisition  Requirements 

The  general  effectiveness  of  a  condition  monitoring  system  is  greatly 
influenced  by  the  type,  frequency,  accuracy,  and  repeatability  of  the 
measurements.  Instrumentation  configuration  and  data  acquisition  design  are 
critical  elements  in  reducing  the  error  magnitude.  The  design  methodology 
must  account  for  sensor  errors  and  further,  quantify  potential  improvements  in 
overall  accuracy  associated  with  Improved  -“nsor  error  characteristics. 

System  modeling  must  consider  errors  associated  with  quantization,  bias  drift, 
flow  distortion,  engine  thermal  diseq-i iibrium,  hysteresis,  and  unsteady 
operation.  Also,  data  sample  rate  must  be  critically  evaluated  against 
accuracy  improvement  and  storage  requirements.  Data  collection  windows  and 
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Table  2.5 

Engine  Performance  Monitoring  Approaches 


APPROACH 


APPROACH 


I  yumem*****  ihr  urn*  mmti  *  aa  am 


I:  MEASUREMENT  TRACKING 

PARAMETERS  ARE  MEASURED 
"MODELS"  ARE  GEOMETRIC  CORRECTIONS 
BASELINE  IS  ACCEPTANCE  STANDARD  AT  .'INGLE  POINT 
II:  PERFORMANCE  INFERENCE 

PARAMETERS  ARE  CALCULATED 
MODEL  IS  ANALYTIC 

BASELINE  IS  CUSTOM  OR  GENERIC  "OPERATING  LINE" 
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Trade-offs  In  Instrumentation  and  Data  Acquisition  System  Design 


SYSTEM  COMPONENT 

TRADE-OFFS 

SENSORS  ACCURACY 

NUMBER 

PLACEMENT 

COST 

RELIABILITY 
vs.  WEIGHT 

MAINTAINABILITY 

POWER  CONSUMPTION 

SAMPLER  SAMPLING  RATE 

(MULTIPLEX)  CHANNEL  ERRORS 

PREFILTERING 

LOCATION 

COMPLEXITY 

WEIGHT 

vs.  RELIABILITY 

POWER  CONSUMPTION 

RECORDER  DATA  WINDOWS 

(ON-BOARD  PROCESSING  ALGORITHMS 

PROCESSOR)  STORAGE  MEDIUM 

COMPLEXITY/RELIABILITY 
vs.  POWER  CONSUMPTION 

WEIGHT 

LOCATION/ACCESS 

DATA  TRANSFER  VOLUME  OF  DATA 

MEDIUM  CAPACITY 

SPEED 

FLIGHT  LINE  AVAILABILITY 

OPERATIONAL  ACCEPTANCE 
vs.  MAINTENANCE  INTEGRATION 
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diagnostic  testing  procedures  should  be  analyzed  relative  to  overall  accuracy 
Improvement  and  the  probability  of  operational  acceptance.  Table  2.6  lists 
important  elements  In  the  trade-off  analysis  of  data  acquisition  and  engine 
Instrumentation  systems. 

2.2.2  Enoine  Modeling  Approaches 


The  measured  parameters  must  be  referenced  to  “normal"  engine  operation. 
The  engine  model  is  an  analytical  tool  for  associating  operating  conditions 
with  measured  variables.  There  are  several  classes  of  models.  The  simplest 
is  a  display  of  the  operating  line  referenced  to  standard  conditions  [3,8]. 
Corrected  variables  are  plotted  at  different  points  versus  one  another.  These 
data  can  be  obtained  from  measurements  on  a  new  engine  or  from  thermodynamic 
equations  [8]. 

Models  developed  experimentally  for  a  particular  engine  are  termed  custom 
models.  Those  determined  analytically  for  a  nominal  or  representative  engine 
are  called  generic  models.  Deviations  of  actual  engine  response  from  model 
response  are  calculated  as  the  distance  between  measured  and  modeled  points 
from  the  custom  or  generic  model  as  shown  In  Figure  2.5.  The  magnitude  of 
these  deviations  is  frequently  compared  against  limits.  Exceedance  of  the 
limit  is  interpreted  as  a  fault,  as  Is  now  discussed. 

A  class  of  generic  models  can  be  formed.  Rather  than  a  display  of  the 
output  versus  a  single  abscissa  variable,  an  analytical  function  can  be 
associated  with  the  output  and  many  abscissa  variables.  This  concept  is 
forma' i zed  in  Chapter  III. 

The  models  described  above  represent  normal  operation  and  are  termed 
baseline  models.  As  the  engine  components  deteriorate  or  age,  their  effect  on 
the  thermodynamic  cycle  shifts  slightly.  The  microscopic  phenomenon  (e.g., 
Table  2.7)  which  cause  aging  are  of  great  interest  to  engine  manufacturers  and 
aircraft  operators  who  design  and  maintain  the  engines  [9,10].  A  component 
model  at  the  phenomenological  level  Is  illustrated  in  Figure  2.6. 

It  is  not  practically  possible  to  calculate  the  extent  of  each 
microscopic  effect  using  typical  operating  data  [9].  The  laws  of 
thermodynamics  can  be  used  within  a  component  level  control  volume  to  model 


Figure  2.5  Corrected  Baseline  Model 


Table  2.7 


PHENOMENOLOGICAL 


Figure  2.6  Levels  of  Modeling  Detail 


Table  2.8 


Example  of  Direct  Comparison  Method  For  The  CF-6  Engine  In 

Stabilized  Cruise 


Figure  2.7  Linear  Performance  Analysis 


Table  2.9 

Linear  Performance  Analysis 


DEMONSTRATED  IN  TEST  CELL  RUNS  ON  COMMERCIAL  ENGINES 

FAULT  COEFFICIENT  MATRIX  MUST  BE  MAPPED  OVER  FLIGHT  ENVELOPE 
REPRESENTING  MN,  RNt  ...  EFFECTS 

BASELINES  DEPENDENT  ON  CONTROL  FUNCTION  IN  MULTIVARIABLE  ENGINE 

INSTRUMENT  ERRORS  MUST  BE  ACCOMMODATED 

NUMBER  OF  MEASUREMENTS  >  NUMBER  OF  PARAMETERS 

DISTURBANCES  RESULT  IN  BIASED  ANSWERS 

ERRORS  IN  MEASURING  ABSCISSA  VARIABLE  BIAS  RESULTS 

WHITE  NOISE  EFFECTS  CAN  BE  LESSENED  BY  AVERAGING 

DISTURBANCES  (e.g.,  CUSTOMER  BLEEDS)  CAN  BE  APPROXIMATELY 
ACCOUNTED  FOR  FROM  PERIPHERAL  MEASUREMENTS  OR  SCHEDULES 

SENSOR  ERRORS  CAN  BE  DETECTED  BY  DETECTING  LARGE  DEVIATIONS 


Table  2.10 
Snapshot  Analysis 


BASED  ON  LINEAR  POINT  DERIVATIVES  OF  PERFORMANCE 
SINGLE  SET  OF  MEASUREMENTS  USED 
NOISE  IN  SENSED  SIGNALS  IMPORTANT 
TYPICALLY  USED  FOR  TEST  STAND  DATA 
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Table  2.11  (Continued) 


these  effects.  Conservation  of  energy  and  mass  are  two  input/output  equations 
(see  Figure  2.7)  which  relate  parameters  such  as  adiabatic  efficiency  and 
effective  area  to  observed  engine  variables  such  as  temperature  and  pressure 
(see  Figure  2.6)  [11].  A  group  of  assumptions  concerning  the  flow  (e.g.. 
constant  radial  velocity  gradients,  constant  specific  heats,  steady 
aerodynamics)  are  made  in  developing  these  nonlinear  component  models  [11]. 
Verification  of  these  data  is  usually  accomplished  from  component  rig 
testing.  It  is  possible  to  use  these  equations  as  a  performance  model  [12]; 
however,  increments!  process  models  are  far  more  accurate  and  efficient  for 
this  purpose  [13,14]. 

The  effect  of  small  deterioration  processes  on  overall  engine  performance 
can  be  assessed  using  modern  estimation  methodology.  In  principle,  each 
deterioration  parameter  is  varied  and  the  change  in  each  output  is  tabulated. 

If  it  is  assumed  that  (1)  the  parameters  affect  the  outputs  in  direct 
proportion  to  their  values  and  (2)  the  effects  are  independent  of  the  other 
parameters,  then  the  resulting  equations  are  defined  as  a  linear  fault- 
coefficient  models  [14,15].  These  are  most  accurate  for  small  changes  in 
component  characteristics  surh  as  those  expected  from  the  deterioration  or 
aging  process.  Notice  that  the  operating  point  about  which  perturations  are 
measured  must  be  fixed.  Hence,  the  operating  point  (baseline)  model  and  the 
fault  models  are  complementary  forms  used  to  compare  deteriorated  measurements 
with  nominal  engine  operation. 

In  order  to  be  successfully  integrated  into  the  maintenance  cycle, 
performance  monitoring  parameters  must  be  directed  to  engine  modules  [16].  If 
a  deteriorated  or  failed  module  is  isolated  at  the  intermediate  (base)  support 
level,  existing  maintenance  and  inspection  procedures  are  geared  to  identify 
work  items  required  to  restore  the  component  to  an  operationally  satisfactory 
state  [17],  or  specify  shipment  to  the  depot  level  maintenance  area.  Thus, 
the  base  level  requirement  for  fault  Isolation  to  the  module  level 
originates.  Further  subclassification  of  the  deterioration  element  (e.g., 
delineating  between  efficiency  and  area  changes)  does  not  improve  the 
effectiveness  of  the  maintenance  outputs  [17].  On  the  contrary,  since  the  net 
error  level  is  adversely  affected  by  an  Increase  in  the  independent 
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deterioration  parameters,  estimating  too  many  fault  elements  can  significantly 
compromise  system  effectiveness. 

2.2.3  Approaches  to  Measurement  Processing 

There  are  several  approaches  to  the  processing  of  performance  data.  In 
general,  deviations  result  from  shifts  caused  by  deterioration  and  failure. 
These  deviations  are  compared  against  fault  parameter  and  inferences 
concerning  engine  health  are  drawn.  This  sequence  transforms  measurements  to 
health  assessment  indicators. 

One  monitoring  approach  detects  consistent  deviations  in  engine 
measurements;  hence,  it  is  termed  the  direct  comparison  method  of  failure 
detection.  On-board  monitoring  procedures  using  this  technique  can  be 
formulated  for  commercial  aircraft  [18,19].  The  commercial  flight  envelope  is 
dominated  by  steady-state  cruise.  If  changes  occur,  this  is  indicative  of  a 
malfunction.  This  method  requires  little  modeling  and  analytical  data 
reduction.  The  arithmetic  sign  and  magnitude  of  consistent  deviations  can  be 
used  to  isolate  common  failure  modes.  Table  2.8  shows  an  example  of  a 
commercially  implementable  failure  matrix  designed  for  direct  comparison 
isolation.  Multiple  faults,  small  deteriorations,  and  sensor  bias  shifts  are 
more  difficult  to  diagnose  with  such  a  system  [18], 

Alternately,  a  fault  coefficient  model  can  be  used  to  invert  the  measured 
deviations  and  calculate  an  estimate  of  the  deterioration  parameters.  This 
procedure  is  termed  the  inferential  method  [3].  The  Mathematical  framework 
for  the  inferential  method  is  the  subject  of  Chapter  III;  however,  the  general 
concept  is  presented  below. 

Linear  performance  analysis  is  summarized  in  Figure  2.7.  A  group  of  p 
measurements,  y,  are  recorded.  An  additional  abscissa  variable,  u,  is 
also  measured.  Curves  or  functions,  f(u),  are  used  to  represent  normal 
engine  operation  as  determined  from  a  fleet  average  (generic)  or  from  a 
particular  (custom)  engine's  running  levels.  One  such  curve  might  be 
corrected  rotor  speed  vs.  EPR.  A  set  of  p  deviations,  ay,  is  calculated 
is  the  difference  in  measured  and  baseline  performance  values  as  shown  in 
Figure  2.7a.  A  linear  coefficient  model  (Figure  2 - 7b)  relates  the  deviations 
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to  engine  parameter  shifts,  the  q  values  of  »  (e.g.,  fan  efficiency  or 
pumping  capacity  changes).  The  equations  are  Inverted  as  shown  in  Figure 
2.7c.  This  inversion  can  be  Imbedded  in  the  more  general  parameter 
identification  and  filtering  context  and  will  be  thoroughly  treated  In  Chapter 
III.  Table  2.9  summarizes  some  of  thi  Important  aspects  of  this  method. 

If  a  single  measurement  is  used  in  the  linear  performance  analysis 
procedure  (see  Table  2.10),  the  parameter  estimates  are  determined  from  a 
snapshot  calculation.  A  snapshot  estimate  gives  an  Indication  of  the  engine 
status  at  a  particular  Instant  of  time.  The  number  of  accurately  detectable 
parameters  must  be  smaller  than  the  number  of  measured  variables.  Also, 
random  and  deterministic  instrument  errors  can  cause  significant  Inaccuracies 
in  the  estimates  [13,20]. 

To  alleviate  the  severe  instrument  accuracy  requirements  of  the  snapshot 
approach,  an  alternative  procedure  can  be  applied.  The  filtering  approach 
combines  previous  parameter  estimates  and  new  measurements  to  form  both  the 
optimal  parameter  estimates  and  estimates  of  error  variance.  Statistical 
analysis  methods  can  be  applied  using  these  descriptors. 

Extraction  of  trends  in  the  parameter  estimates  and  accurate 
quantification  of  the  trends  imbedded  in  data  scatter  are  important  secondary 
processes.  Trends  can  be  linked  with  engine  life  usage.  While  the  level  of 
component  performance  is  a  function  of  the  engine  build  and  particular 
physical  dimensions,  the  change  in  its  performance  can  be  associate'"  directly 
with  deterioration.  Special  advanced  mission  and  simulated  mission  endurance 
test  programs  can  be  used  to  measure  observed  parameter  changes  for  components 
experiencing  expected  installed  usage  [21,22].  Trending  parameters  to  measure 
changes  as  a  function  of  usage  and  to  predict  when  an  allowable  level  is 
exceeded  is  an  extremely  attractive  aid  for  maintenance  policy  formulation. 

2.3  PRACTICAL  ASPECTS  OF  CYCLE  MONITORING  ALGORITHMS 

Practical  issues  associated  with  the  monitoring  problem  will  now  be 
identified.  These  issues  include  data  acquisition  and  storage,  measurement 
processing  and  output  management.  Table  2.11  lists  the  important  areas  which 
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must  be  addressed  in  each  category  and  presents  the  monitoring  methods  which 
will  be  used  to  address  these  issues. 

2.3.1  Three  Areas  of  Practical  Concern 


Data  acquisition  gem  rally  involves  the  repeatable,  accurate  measurement 
of  physical  quantities  in  a  harsh,  dynamic  operating  environment  over  an 
extended  period  of  time.  The  state  of  the  art  in  transducer  hardware  and  data 
recording  systems  addresses  the  physical  aspects  associated  with  these 
problems.  Data  processing  must  account  for  these  error  sources  and  produce 
results  which  minimize  the  inaccuracies.  Random  error  due  to  sensor  and 
channel  noise  can  be  reduced  by  averaging.  Advanced  algorithms  filter  the 
data  and  use  groups  of  data  points  taken  at  different  parts  of  the  operating 
envelope  to  reduce  error  levels  further.  The  best  data  rate  can  be 
established  by  an  analysis  of  the  noise  in  the  measurement  signal.  The 
optimum  number  of  sampled  points  is  then  derived  [23].  Sensor  failures  are 
easily  detected  if  they  change  significantly  (hard-over).  Leaks,  shorts,  and 
intermittent  phenomena  are  more  difficult  to  detect.  In  general,  the  use  of 
the  engine  model  to  validate  the  set  of  measurements  before  the  measurements 
are  used  to  update  the  parameter  estimates  produces  more  accurate  detection 
and  isolation  of  sensor  errors  [24,25]. 

Problems  caused  by  build  variations  and  hardware  changes  (module  swaps) 
during  the  engine  lifetime  must  be  addressed.  Calculation  of  the  operating 
baseline  and  sensor  calibrations  can  be  performed  after  sach  maintenance 
action.  Alternately,  a  reinitialization  of  the  confidence  levels  in  the 
filter  algorithm  will  discard  Information  about  unaffected  parameters. 

Output  display  Is  significant  and  has  received  the  least  attention  in  the 
development  of  current  diagnostic  systems.  Decision  processes  can  be 
statistically  formulated  and  the  optimum  decision  can  be  determined  from  the 
data.  Often,  the  experience  and  judgement  of  the  logistics  manager  is 
preferred  to  automatic  decision  outputs.  Thus,  performance  estimates  should 
be  organized  and  displayed  to  allow  human  judgement  to  be  exercised. 
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2.3.2  Thermodynamic  Cycle  Monitoring  MethodolQ' 


The  thermodynamic  cycle  monitoring  approach  [3]  uses  estimation 
algorithms  to  process  engine  performance  data.  These  estimation  algorithms 
are  derived  using  maximum  likelihood  statistics.  This  principle  simply  states 
that,  for  a  given  set  of  data  from  an  experimental  process,  there  is  a  model 
which  most  likely  generated  that  data.  Many  tractable  maximum  likelihood 
“methods'1  are  based  on  the  assumption  that  the  model  uncertainty  is  described 
by  a  Gaussian  distribution.  This  assumption,  combined  with  the  assumption  of 
an  underlying  linear  model,  has  led  to  very  effective  data  processing 
algorithms.  Unfortunately,  the  engine  model  is  highly  nonlinear  and  the 
assumption  of  Gaussian  statistics  In  descriptions  of  the  model  uncertainty  is 
frequently  not  viable. 

The  theoretical  basis  of  this  formulation  lies  in  simultaneous  solution 
of  both  model  equations  and  the  likelihood  criterion,  and  is  presented  in 
detail  in  Chapter  III.  Further  extensions  ire  required  to  integrate  the 
presence  of  sensor  errors.  The  thermodynamic  cycle  monitoring  problem  can  be 
characterized  by  a  few  essential  theoretical  tasks. 

There  are  three  distinct  aspects  of  the  development  process  (see  Figure 

2.8). 

(1,  The  development  of  quasi-linear  regression  models  to  match 
nominal  and  perturbed  engine  behavior. 

(2)  The  selection  of  module-directed  fault  parameters  based  on 
acceptable  error  levels  and  system  configuration. 

(3)  The  use  of  the  models  In  conjunction  with  a  general  maximum 
likelihood  parameter  estimation  and  trending  algorithm  to 
derive  fault  indicators  from  engine  performance  data. 

2.4  SUMMARY 

Engine  monitoring  has  been  discussed  in  general.  A  large  number  of 
health  indices  can  be  used  to  evaluate  the  status  of  an  operating  engine. 
Thermodynamic  performance  analysis  has  the  potential  to  produce  actual 
component  directed  health  indicators,  but  the  useful  implementation  of  a 


* 


DEVELOPMENT 
QUASI-  LINEAR 
REGRESSION 
MODEL 


t 

SELECTION  OF 
MODULE 

DIRECTED  FAULT 
PARAMETERS 

\ 

r 

MAXIMUM 
LIKELIHOOD 
PARAMETER 
ESTIMATION 
AND  TRENDING 


Figure  2.8  Development  of  Advanced  Monitoring  Algorithms 
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system  requires  careful  design  of  the  data  acquisition,  processing  and 
presentation  software.  The  thermodynamic  cycle  monitoring  method  discussed  In 
more  detail  In  the  subsequent  chapters  represents  a  system  algorithmic 
framework  from  which  a  viable  Implementation  can  be  derived. 
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III.  MATHEMATICAL  FOUNDATIONS  OF  THERMODYNAMIC 
CYCLE  MONITORIfG  (TCM) 


3.1  INTRODUCTION 

The  previous  chapter  Introduced  the  engine  performance  monitoring 
problem,  current  approaches  to  its  solution,  and  some  practical  aspects  that 
must  be  addressed  by  cycle  monitoring  systems.  It  1$  Important  to  consider 
the  general  formulation  of  the  data  processing  algorvihm  when  deriving  a 
procedure  for  handling  the  engine  monitoring  requirements.  By  specializing 
the  general  solutions,  a  generic  methodology  will  evclve  that  Is  applicable 
over  a  wide  class  of  nglne,  Instrumentation,  and  processing  hardware 
configurations.  In  this  chapter,  the  general  problem  is  formulated  and 
algorithms  for  thermodynamic  cycle  monitoring  are  developed* 

3.2  MODELING 

The  general  theoretical  requirements  of  the  development  are  shown  In 
Table  3.1.  These  requirements  are  driven  by  the  general  attributes  of  the 
overall  monitoring  problem  (Table  3.2)  to  produce  a  family  of  algorithms  that 
can  be  implemented  within  a  group  of  hardware  and  data  processing  scenarios. 
The  input/output  requirements  can  be  loosely  represented  as  combining  engine 
data  and  prior  condition  Indices  (Table  3.3)  to  form  new  condition  Indices  and 
module  or  component-directed  diagnostic  Indicators.  The  goals  in  formulation 
of  the  problem  solution  (Table  3.4)  represent  desirable  features  for  a  generic 
system,  l.e.,  one  that  provides  a  large  percentage  of  engine-type  Independent 
processing  software  and  that  can  be  fa:  ioiy  altered,  modified,  and  updated 
without  significant  programming  impact.  Linear  models  provide  this  type  of 
manipulation  flexibility,  but  do  not  achieve  the  accuracy  levels  in  modeling 
installed  engine  performance. 

The  thermodynamic  cycle  monitoring  (TCM)  approach  uses  a  generic  baseline 
and  fault  parameter  model  combined  Into  a  class  of  algebraic  equations  known 
as  quasl-1 Inear  regression  (QLR)  models.  These  models  are  nonlinear  In  engine 


Table  3.1 


General  Theoretical  Requirements 


PROBLEM:  SPECIFY,  ACQUIRE,  AND  PROCESS  ENGINE  DATA  TO 

PROVIDE  GAS  PATH  DIAGNOSTIC  INDICES 

SOLUTION:  INTEGRATE  SENSORS,  DATA  PROCESSORS,  DATA  FORMATS 

WITH  A  SYSTEMATIC  FRAMEWORK 

YIELDS:  COMPREHENSIVE  ALGORITHMIC  STRUCTURE  AND  UTILIZATION 

METHODOLOGY 


Table  3.2 

Factors  Driving  The  Selection  Of  A  Theoretical  Formulation 

MOOEL  COMPLEXITY/CAPABILITY 

ABILITY  TO  ISOLATE  ENGINE  AND  SENSOR  FAULTS  IN  REAL-TIME  OR 
OFF-LINE  ENVIRONMENT 

ABILITY  TO  TREAT  A  VARIETY  OF  DATA  SETS 

DEMONSTRATED  COMPATIBILITY  WITH  VARIETY  OF  DIGITAL  PROCESSORS 

UTILITY  0£  ALGORITHMIC  OUTPUTS 
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Table  3.3 

Fault  Monitoring  Problem 


'.7 

GIVEN:  1.  NOISY  SETS  OF  MEASUREMENTS 

2.  PRIOR  INFORMATION 
PRODUCE:  1.  UPDATED  ENGINE  STATUS 

2.  FAILURE  INFERENCES  (ENGINE/SENSOR/CONTROL) 

3.  MODULE-DIRECTED  INDICES 

4.  OPERATIONALLY  SIGNIFICANT  OUTPUTS 


Table  3.4 

Problem  Formulation  Goals 


I 


in 


NONLINEAR  REPRESENTATION  OF  GENERIC  ENGINE  BASELINE  AND  FAULT 
COEFFICIENTS  —  CONTROL  INDEPENDENT 

INCORPORATES  FLIGHT/POWER  ENVELOPF  CONTINUOUSLY 

STANDARD  MODEL  FORMAT 

EFFICIENT  AND  FLEXIBLE  EVALUATION  CAPABILITY 
ACCURACY/COMPLEXITY  TRADE-OFFS  APPARENT 
CORE  CONSERVATIVE 
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operating  point  variables  and  linear  In  Incremental  fault  parameters.  A 
regression  procedure  Is  used  to  determine  the  particular  model  equations 
accurately  for  each  engine  type  considered.  The  QLR  model  form  and 
algorithmic  Implementation  are  chosen  so  that  matrix-type  operations  can  be 
performed  on  the  nonlinear  equations.  This  yields  extremely  efficient  and 
flexible  processing  procedures  that  would  otherwise  be  impossible  at  the  same 
level  of  generality  and  model  complexity. 

The  quasi-1 inear  engine  model  Is  assumed  to  be  of  the  form: 

y  -  90(x,u)  +  ge(x,u)e  +  gw(x,u)w  +  h^  (x,u)b  +  v  (3.1) 

where 

y  Is  a  vector  of  sensed  outputs  (e.g.  y\  *»  PS3,  y%  •  N2,  . .., 
etc), 

x  Is  the  engine  state  vector, 

u  Is  the  control  vector, 

e  Is  the  deviation  of  linear  fault  parameters  (e.g.,  fan 
efficiency,  flow  area,  etc.)  from  the  nominal, 

w  Is  the  deviation  of  disturbance  parameters  from  nominal, 

4  Is  the  instrument  error  parameters  (e.g.,  bias,  scale  factor, 

etc.), 

v  Is  random  noise  (e.g.,* channel  noise,  engine,  disequilibrium, 
etc.) 

g0  is  the  nonlinear  polynomial  baseline  model, 
g9  Is  the  fault  model, 

gw  Is  the  disturbance  model,  and 

h^  is  the  Instrument  error  model. 

The  baseline  model  gD  produces  an  estimate  of  the  vector  y  for  a  nominal 
or  average  engine  (l.e. ,  ©  »  w  ■  0  -  v  -  0)  given  x  and  u.  It  is  assumed 
that  the  sensitivity  of  y  to  variations  In  the  parameters  e,  w,  and  4  Is 
small  when  compared  to  the  effects  of  state  and  control  variables  such  as 
rotor  speed  and  power  lever  angle.  Thus,  y  can  be  modeled  as  a  linear 
function  of  e,  w,  and  4  for  a  fixed  operating  point  (x,u).  However,  the 
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SENSOS  OUTPUT  y 


SET  POINT  (x,u) 


y  ■  g0(x.u)  +  g0(x,u)e  j 

i 

•i 


1 


Figure  3.1  Graphical  Illustration  of  the  Engine  Model 


38 


■it'tyJiH  ■-( :  >i- « 


,1 


J 

"i 


functions  gg  ,  gw,  and  h^  may  be  nonlinear  in  x  and  u.  Hence,  Eq. 

(3.1)  is  called  a  quas 1-1 Inear  engine  model.  Figure  3.1  illustrates  a 
simplified  version  of  Eq.  (3.1).  The  equation  structure  models  deterioration, 
instrument  errors  and  disturbance  effects  as  continuously  varying  functions  of 
the  operating  point.  The  development  of  the  quasi-1 inear  model  will  be 
described  next. 

First,  the  development  of  a  generic  baseline  model  g0  is  described. 

The  goal  is  to  specify  a  function  which  accurately  predicts  sensed  variables, 
y,  for  a  nominal  engine  in  the  fleet.  While  a  set  of  nonlinear  thermodynamic 
equations  could  be  derived  from  physical  principles,  the  resulting  equations 
would  not  match  actual  operating  data  very  well.  More  accurate  equations  can 
be  developed  directly  from  the  operating  data.  Since  operating  data  do  not 
represent  perfect,  noiseless  observatons  of  a  nominal  engine,  regression 
analysis  is  used  to  "average  out"  noise,  errors,  deterioration  effects,  etc. 
Regression  analysis  can  determine  nonlinear  polynomial  functions  of  a  set  of 

Independent  variables  that  be^t  match.  In  a  least-squares  sense,  a  set  of  data 

points.  In  other  words,  the  procedure  fits  analytical  curves  to  the  operating 

line  data.  While  basic  formulation  of  this  method  was  developed  several 

hundred  years  ago,  recent  analytical  and  computational  results  have 
significantly  Improved  Its  accuracy  and  applicability. 

The  regression  problem  Is  to  find  a  function  g0(x„u)  which  minimizes 
the  squared  error  between  data  points  and  the  curve  gQ.  This  problem  can 
be  expressed  as 

N  2 

SS  -  min  2  ($(j)  _  y(J))  ,  y(j)  .  g„(x^,  u^)  (3.2) 

90  >1  ° 

where  N  is  the  number  of  observations,  y^  refers  to  the 
observation  of  y.  The  predicted  value  of  y^  is  called  y(j)  given 
x(j)j  The  quantity  y-y^  is  called  the  residual  of  the  jth 

observation.  Note  that  Eq.  (3.2)  represents  several  regression  problems 
simultaneously,  one  for  each  sensed  variable  yi  in  the  vector  y.  The 
first  problem  with  this  formulation  is  that  the  independent  variables  x,u 
are  not  perfectly  known.  These  are  replaced  with  observable  quantities  y. 

The  second  problem  is  that  the  form  of  the  function  gQ  (or  y)  must  be 
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specified,  y  must  be  chosen  from  a  large  number  of  nonlinear  polynomial 
functions.  The  problem  becomes  one  of  choosing  model  terms  from  a  large  set 
of  potential  independent  variables.  The  equations  should  be  accurate  (i.e.  SS 
should  be  small)  yet  minimially  complex  (i.e.,  as  few  model  terms  as 
possible).  Note  that  the  sum  of  squares  criterion  SS  is  inversely  related 
to  the  R2  values:  small  values  of  SS  correspond  to  large  R2  values. 
Techniques  of  optimal  set  regression  which  can  identify  the  best  set  of 
explanatory  (Independent)  variables  among  many  possible  subsets  have  recently 
been  developed.  These  procedures  have  been  Implemented  In  the  MODGEN  (model 
generation)  program  [26], 

The  baseline  model  development  consists  of  three  major  parts: 

(1)  data  screening; 

(2)  calculation  and  selection  of  regression  equations;  and 

(3)  computer  implementation  and  model  validation. 

The  purpose  of  data  screening  is  to  produce  a  uniform  data  sample  consisting 
of  stabilized  or  repeatable  data  frames.  Not  all  of  the  recorded  data 
represent  normal  engine  operating  conditions  because  of  sensor  failures, 
outlier  samples,  equipment  malfunctions,  or  other  error.  Because  the 
regression  procedure  uses  a  sum  of  squares  criterion,  inclusion  of  outlier 
data  could  significantly  bias  the  model  computation.  Little  information  is 
lost  in  this  process  when  a  large  data  population  Is  used. 

The  screened  data  set  Is  used  as  input  to  the  MODGEN  program  for 
calculating  selecting  regression  equations.  Figure  3.2  shows  the  trade-off 
between  model  complexity  and  model  accuracy.  The  point  where  the  trade-off 
curve  crosses  the  uncorrelated  residual  level  is  often  the  best  choice  for  the 
number  of  model  terms. 

Figure  3.3  shows  a  graph  of  typical  baseline  model  involving  only  one 
Independent  variable.  The  difference  between  the  observations  and  baseline 
model  predictions,  I.e.  the  residuals,  is  plotted  in  Figure  3.4.  Also  shown 
in  Figure  3.4  is  the  average  fit  error,  o.  The  value  a  indicates  the 
average  error  in  the  estimate  y  of  the  actual  measurement  y.  The  residuals 
should  be  randomly  distributed  about  zero  if  the  model  is  adequate. 
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Figure  3.5  A  Typical  Baseline  Model 
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Approximately  68  percent  of  the  residuals  should  fall  In  the  Interval  [-0, 

+0].  A  typical  baseline  model  Is  shown  In  Figure  3.5. 

Once  the  regression  equations  are  chosen  for  each  operating  variable,  the 
equations  must  be  stored  In  the  computer  In  an  efficient  manner.  The  computer 
representation  of  the  model  should  minimize  storage  requirements,  yet  also 
permit  systematic  manipulation  of  the  equations  as  needed  by  the  TCM 
algorithms.  The  computer  representation  of  a  typical  model  is  shown  In  Figure 
3.6.  The  model  shown  In  Figure  3.6  is  a  full  engine  model  including  the 
baseline  model  and  fault  models.  The  average  fit  error  of  the  model  is 
compared  with  the  MODGEN  calculations  to  validate  the  model.  The  validation 
procedure  ensures  that  the  model  has  been  implemented  correctly  The 
methodology  for  generating  the  fault  model  will  be  described  next. 

The  fault  model  ge  expresses  the  effect  of  engine  degradation  (i.e., 
perturbing  e)  on  the  sensor  readings  y  (see  Figure  3.1).  Since  the  engine 
fault  parameters  are  not  directly  observable,  the  fault  model  cannot  be 
developed  from  operating  data.  In  lieu  of  operating  data,  simulated  data  are 
generated  from  an  engine  status  deck  which  solves  the  mechanical  and 
thermodynamic  equations  for  the  engine.  While  simulated  data  may  not  very 
well  match  the  baseline  model  derived  from  operating  data.  It  Is  assumed  that 
changes  In  the  measurements  caused  by  perturbing  fault  parameters  are 
accurately  reflected  hy  the  status  deck. 

To  quantify  the  effect  of  decreasing  fault  parameters  on  the 
measurements  y,  two  types  of  simulation  data  are  generated.  First,  a  nominal 
undeteriorated  (©  «  0)  configuration  Is  modeled  at  a  moderate  number  of 
conditions.  Although  the  status  deck  models  behavior  in  all  parts  of  the 
operating  envelope,  operating  data  will  be  recorded  In  a  significantly  reduced 
portion.  The  specific  conditions  for  data  generation  are  chosen  to  match  the 
range  of  data  collected  from  the  engine  monitoring  system.  Subsequent  data 
are  generated  at  these  same  conditions,  but  with  a  single  fault  parameter, 
e.g.  fan  efficiency  or  turbine  nozzle  area,  varied  through  representative 
values.  Then  the  changes  in  the  measurements  ay  from  their  nominal 
configuration  are  recorded.  These  data  are  used  to  calculate  the  fault  model 
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Figure  3.6  Computer  Representation  of  QLR  Model 
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Figure  3.7  Fault  Model  Development 


To  illustrate  this  procedure,  let  ay  be  the  difference  between  y  at 
the  nominal  configuration  (e  -  0)  and  y  at  the  deteriorated 
configuration  (e  0).  A  typical  data  set  generated  by  perturbing  a  single 
6^  and  observing  the  effect  on  yj  is  shown  in  Figure  3.7.  A  regression 
procedure  is  then  used  to  derive  the  fault  model  which  best  matches  (i.e., 
minimizes  the  sum  of  squares)  the  simulated  data.  This  regression  is 
performed  with  the  restriction  that  the  models  are  linear  in  the  fault 
parameters  e.  If  the  fault  parameter  has  an  insignificant  effect  on  the 
output  quantity,  the  regression  procedure  will  indicate  this,  and  the 
corresponding  terms  will  not  be  included  In  the  fault  model.  The  resulting 
model  will  then  be  in  the  quasi-linear  form  of  Eq.  (3.1).  The  fault  model 
terms  are  then  incorporated  with  the  baseline  model  to  produce  a  full  QLR 
model.  The  model  is  again  checked  to  verify  that  the  computer  implementation 
is  correct.  The  model  generation  procedure  is  summarized  in  Figure  3.8.  A 
typical  QLR  model  for  a  single  operating  variable  is  shown  in  Figure  3.9. 

The  full  QLR  model  forms  the  basis  for  an  analysis  to  estimate  the  fault 
parameters,  e.  However,  since  there  are  usually  many  fault  parameters,  a 
linear  combination  of  these  parameters  will  be  estimated  instead.  The 
derivation  of  these  module-directed  fault  parameters  is  described  next. 

3.3  PARAMETERIZATION 

The  goal  of  the  estimation  procedure,  as  described  in  Section  3.5,  is  to 
estimate  meaningful  engine  health  parameters  accurately.  Prior  to  the 
development  of  an  estimate  analysis,  it  is  important  to  consider  which 
parameters  can  and  should  be  estimated.  There  are  two  major  considerations  in 
a  parameterization  procedure.  First,  it  must  be  possible  to  estimate  the 
parameters  accurately.  In  general,  as  the  number  of  parameters  increases,  the 
accuracy  with  which  each  can  be  estimated  decreases.  Second,  the  parameters 
should  be  physically  meaningful  and  useful.  The  fault  parameters  discussed 
thus  far  have  been  rather  general.  Instrument  parameters,  cycle  parameters, 
and  disturbance  inputs  are  available  during  the  generation  of  the  QLR  model. 

In  general,  these  are  not  the  appropriate  parameters  to  estimate  from  an 
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•  OPTIMAL  SUBSET 
REGRESSION 


•  FAULT  PARAMETERS 

•  REPRESENTATIVE  RANGES 

•  PERTURB  SINGLY 

•  REDUCE  OPERATING  POINTS 


Figure  3.8  Model  Generation  Procedure 


Table  3.5 


Module-Directed  Performance 


PROBLEM:  MANY  POSSIBLE  FAULT  PARAMETERS  PRECLUDED  ACCURATE 

ESTIMATION  (UNIQUENESS  PROBLEM) 

OBSERVATION:  MAINTENANCE  DECISION  IS  CONCERNED  WITH  PERFORMANCE 

OF  A  MAINTENANCE  ITEM  (OR  MODULE) 

QUESTION:  IS  IT  POSSIBLE  TO  COMBINE  FAULT  PARAMETERS  TO  FORM 

MODULE-DIRECTED  PARAMETERS  WHICH  REFLECT  MODULE 
STATUS  AND  CAN  BE  ACCURATELY  ESTIMATED? 
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operational  viewpoint  In  the  sense  that  they  present  too  much  data  to  the 
maintenance  personnel. 

The  candidate  deterioration  factors,  e.g.  areas  and  efficiency,  were 
determined  by  the  engine  simulation.  These  may  not  represent  efficient 
module-directed  indicators.  For  example,  the  F100  core  module  contains  the 
compressor,  burner,  and  high-pressure  turbine.  These  components  are 
represented  by  five  deterioration  (fault)  parameters.  Condensing  the 
information  into  one  module-directed  indicator  increases  the  estimation 
accuracy.  These  considerations  are  summarized  in  Table  3.5. 

An  example  of  the  method  is  shown  in  Figure  3.10  for  a  very  simple 
problem.  Initially,  two  parameters  are  to  be  uniquely  estimated  from  a  single 
measurement;  this  impossibility  is  manifested  by  a  singular  information 
matrix.  However,  a  single  linear  combination  of  these  parameters  can  be 
estimated.  The  increase  in  accuracy  with  the  reduction  in  the  number  of 
variables  is  illustrated  in  this  example. 

A  procedure  for  transforming  the  generating  parameter  set  into  a  smaller 
set  of  hardware  or  module-directed  parameters  is  derived  below. 

A  general  requirement  for  a  reparameterization  of  the  problem  is  shown  in 
Figure  3.11.  A  transformation  is  calculated  that  increases  the  accuracy 
levels  of  the  parameter  set.  The  physical  nature  of  the  parameters  will 
clearly  place  restrictions  on  the  allowable  combination  of  parameters.  Thus, 
for  example,  a  parameter  measuring  core  gas  path  performance  should  be 
considered  for  a  core-directed  diagnostic  display. 

A  method  of  geometric  projection  is  used  to  derive  a  set  of  optimized, 
module-directed  parameters.  Consider  a  single,  reduced  parameter,  ©,  which 
will  be  some  linear  combination  of  a  subset  of  the  generating  parameters, 

e  £  e 

This  can  be  written  as  follows: 

©  -  TTe 

T  -  Ctj_,  tr,  0  ...  0] 

where  it  has  been  assumed  that  6  is  a  function  of  the  first  r  ©  values. 

The  subspace  of  parameters  (r  dimensional)  spanned  by  the  r  allowable 
parameters  will  contain  the  optimal  ©.  The  linear  combination,  ©  (which 
will  be  restricted  to  pure  rotations  to  avoid  distortion  of  the  metric),  will 
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Figure  3.10  Module-Directed  Performance  Exampl 


ESTIMATION  ACCURACY:  C0V(«)  -  M_1 

PARAMETER  TRANSFORMATION:  o  -  TTo 
MODIFIED  COVARIANCE:  COV(e)  -  TMTT 

.  M 


DECOMPOSITION: 
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Choose  T  such  that  COV^)  «  COV(e2) 

Then  estimate  only  e^: 

cov^)  «  m i\  +  mjJ  m12  cov(52)  m21m^^  M i\ 


Figure  3.11  Module^Di rected  Performance  Parameters 
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have  the  largest  projection  in  the  direction  of  the  largest  eigenvalue  of  M 
(i.e,  in  the  eigendirection  of  that  eigenvalue)  of  any  vector  in  the 
subspace.  Calculation  of  this  projection  will  produce  the  required  rotation 
and  the  required  reducing  transformation,  T. 

The  procedure  can  be  extended  to  a  large  number  of  reduced  parameters  by 
ranking  the  largest  projection  on  the  largest  eigenvalues  of  M  and 
sequentially  selecting  rotations  and  eliminating  eligible  eigenvectors.  This 
projection  method  has  been  implemented  and  is  shown  in  Figure  3.12.  The  final 
result  will  be  a  set  of  module-directed  TCM  parameters  that  represent  subsets 
of  the  original  set,  or 

(rxl)  (rxq)  *  (qxl) 

The  physical  interpretation  of  this  procedure  is  that  information 
concerning  estimated  parameters  is  processed  in  the  most  favorable  combination 
from  a  structural  viewpont.  If  the  sensor  set  is  not  inclusive  enough  or  does 
not  contain  sufficiently  accurate  probes,  unique  estimates  of  all  cycle 
parameters  will  not  be  available  from  any  estimation  method.  It  remains  to 
select  linear  combinations  of  parameters  that  have  a  physical  interpretation 
in  the  engine.  This  can  be  Illustrated  as  follows.  Suppose  that  a  parameter 
directed  toward  the  high-pressure  turbine  were  calculated  as  follows: 

°HT  *  alAAHT  +  a2  AnHT 

i.e.,  the  reduced  parameter  is  a  combination  of  the  efficiency  and  area  change 
of  the  component.  Under  normal  operating  conditions,  an  aging  turbine  will 
exhibit  a  decrease  in  efficiency  and  an  increase  in  effective  area  due  to 
erosion,  seal  leakage,  and  other  microscopic  processes.  Clearly,  unless 
a^  and  a2  are  opposite  in  sign,  the  effect  on  the  module-  directed 
turbine  parameter  will  be  attenuated.  Thus,  the  projection  procedure  result 
must  be  evaluated  vis  a  vis  the  nature  of  observed  deterioration  modes  to 
verify  the  appropriateness  of  the  selected  reduced  parameter  identity. 
Adjustments  in  the  parameterization  may  be  made  by  forcing  alternate 
projections  to  be  selected  in  the  calculation  process. 

A  group  of  parameter  evaluation  methods  have  been  reviewed.  The  QLR 
model  can  be  manipulated  using  these  transformations  into  a  form  that  will 
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produce  optimal,  module-directed  estimated  parameters  from  the  TCM  algorithm. 

In  the  last  section,  a  sensor  validation  procedure  is  presented  that  uses  the 
identified  engine  model  as  a  basis  for  diagnosis  of  failed  sensor  inputs  in  a 
new  set  of  data. 

3.4  SENSOR  VALIDATION 

An  important  consideration  in  processing  engine  health  monitoring  data  is 
the  detection  and  isolation  of  data  scans  that  include  failed  or  disconected 
channels.  In  addition  to  actual  probe  failure,  uninstalled  engine  run  data 
often  will  not  have  a  full  data  complement.  In  practical  operation,  sensor 
channels  may  remain  failed  for  long  periods  of  operating  time  because  a 
maintenance  opportunity  has  not  arisen.  In  order  to  include  partially  failed 
data  in  the  processing,  some  form  of  detection  and  reconstruction  is 
desirable.  The  general  cross-  validation  procedure  discussed  below  represents 
an  efficient  and  accurate  algorithm  built  on  the  flexibility  of  the  QLR  design 
and  the  accuracy  levels  associated  viith  the  parameter  identification  process. 
These  attributes  are  summarized  in  Table  3.6. 

The  sensor  validation  algorithm  preprocesses  sensor  measurements,  in 
conjunction  with  the  estimated  QLR  models,  to  determine  if  the  measured  values 
are  statistically  consistent  with  previously  measured  values.  Parameter 
estimate  uncertainties  are  used  to  establish  the  testing  threshold.  Since 
these  are  reset  bw  t.  lintenance  activity,  threshold  values  are  adaptively 
changing  to  the  uncertainty  in  the  model.  False  alarm  rates  are  low. 
Inconsistent  data  channels  are  flagged  as  sensor  failures  and  the  sensor  data 
value  is  calculated.  This  process  acconmodates  intermittent  channel  failures 
without  modification  of  the  estimation  process. 

Table  3.7  illustrates  the  process  on  a  linear  model.  A  test  variable 
(which  is  normally  distributed)  is  estimated  and  exceedances  are  detected. 
Failed  channels  are  discarded  and  the  model  is  used  to  generate  new  test 
variables.  The  process  iterates  until  the  failed  channel  coincides  for  two 
iterations.  Clearly,  this  process  cannot  be  successfully  completed  for  a 
general  set  of  instrument  failures.  The  conditions  will  allow  a  table 
reconstruction  of  the  failed  channels  from  the  unfaileu  channels  to  determine 
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Table  3.6 


Sensor  Diagnostic  Algorithm 


DATA  PREPROCESSING 

REJECTION  OF  OUTLIERS/FAILED  CHANNEL  DETECTION 
RECONSTRUCTION  OF  FAILED  CHANNEL  FOR  FILTER 
PROVIDES  ABILITY  TO  PROCESS  INCOMPLETE  SENSOR  SETS 
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Table  3.7 

Sensor  Diagnostics  -  General  Cross-Validation  Linear  C 


STEP  1:  DETECTION 


x  ■  Ax  +  w:  N(0,Q) 
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y  -  Ay  Measurements 
y  ■  x  +  v  v:  N(0,R) 
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DEFINE: 
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VARIABLES 


GO  TO  STEP  1  UNTIL  OUT-OF-RANGE  AND  NORMAL  SETS  MATCH 


STEP  3:  RECONSTRUCTION 
SET  yj  .  y1 
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the  set  of  Isolatable  channel  failures.  This  condition  may  be  restated  as  a 
mathematical  condition  on  the  model  matrix  A  as  follows.  The  system  of  p 
sensor  channels  will  be  r  isolatable  if  every  rxr  submatrix  of  the  model 
A  is  invertible.  In  general,  the  rank  of  the  model  matrix  will  be  p-m 
where  m  is  the  number  of  independent  setting  parameters  of  the  engine  which 
are  mt  ensors,  e.g.,  in  the  F100,  PT2,  TT2,  and  PLA  are  required  to  set 

the  op‘r  ing  point.  Thus,  at  most,  8  out  of  11  sensor  channels  will  be 
isolatable  at  a  given  linearization  point.  In  practice,  the  structure  of  A 
will  be  such  that  many  failure  combinations  of  up  to  six  sensor  failures  can 
be  accommodated  by  the  procedure.  This  practical  limit  is  above  that  which  is 
normally  encountered  in  installed  and  uninstalled  data.  If  a  particular 
sensor  scan  cannot  be  isolated,  the  algorithm  will  indicate  that  all  channels 
have  failed  and  the  data  can  be  discarded. 

The  model  used  to  validate  the  channels  is  the  QLR  representation 
including  sensor  and  parameter  variance  estimates.  If  a  channel  fails,  the 
reconstructed  channel  is  formed  from  the  a  priori  model.  Therefore,  no 
inconsistent  information  is  passed  into  the  estimator  and  the  effect  of 
channel  failures  will  be  automatically  accommodated.  This  feature  allows  the 
estimation  algorithm  to  be  independent  of  the  sensor  diagnostics,  which  can 
considerably  increase  the  flexibility  of  the  software. 

The  nonlinear  model  procedure  is  illustrated  in  Table  3.8.  The  method  is 
identical  to  the  linear  case  with  the  linearizations  at  the  operating  point 
used.  The  thresholds  are  calculated  from  sensor  and  parameter  uncertainty 
levels.  They  are  recalculated  for  each  failure  configuration.  The 
calculation  does  not  require  additional  linearizations,  but  rather  proceeds 
from  a  simple  column  operation  on  the  initial  linearized  matrices.  The 
calculations  described  in  the  table  are  supported  by  the  same  QLR  software 
that  is  used  in  the  parameter  estimation  routines.  This  factor  makes  the 
implementation  of  the  generalized  cross-validation  procedure  viable.  The  flow 
diagram  for  this  procedure  is  shown  in  Figure  3.13. 

The  threshold  levels  range  between  5  percent. and  10  percent  of  the 
measured  value.  The  mt  'iod  has  been  verified  to  detect  correctly  an  arbitrary 
set  of  out-of-tolerance  channels.  Table  3.9  illustrates  an  iteration  to 
detect  a  low  ^  reading.  During  the  first  pass  using  the  low 
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Table  3.8 

General  Cross-Validation  (Nonlinear  Case) 


CONSIDER  SPLITTING  VARIABLES  INTO  TWO  GROUPS: 
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Table  3.8  (Continued) 
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Figure  3.13  General  Cross-Validation  Processing  Flow 


Table  3.10 


Sensor  Validation  Algorithm 


USES  ENGINE  MODEL  DERIVED  FROM  OPERATING  DATA  INCLUDING  CHANNEL 
ERROR  VARIANCE 

USES  RANGE  CHECKS  FOR  HARD  FAILURES 

USES  CHANNEL  ERROR  STATISTICS  FOR  SOFT  FAILURES 

DETECTS  MULTIPLE  FAILURES  WITHOUT  FAULT  TREE 

ESTIMATES  FAILED  CHANNEL  READING  FOR  SUBSEQUENT  DIAGNOSTIC 
UTILIZATION 


reading,  seven  channel  failures  are  detected.  The  sensor  deviation  and 
threshold  are  shown  In  the  table.  On  the  second  pass,  the  two  In-bound 
channels  are  used  to  solve  for  the  remaining  seven  channels.  The  thresholds 
are  adjusted  to  account  for  the  loss  of  precision  in  this  process.  On  the 
second  and  subsequent  pases,  one  is  out  of  tolerance  and  this  channel 
Is  reconstructed.  These  data  represent  actual  F100  operating  data.  Results 
discussed  in  Chapters  V  and  VI  are  extremely  promising. 

A  sensor  diagnostic  routine  that  uses  a  general  cross-  validation 
procedure  has  been  described.  The  attributes  of  the  algorithm  are  summarized 
in  Table  3.10.  The  algorithm  is  supported  directly  with  the  QLR  software 
library  and  provides  a  powerful  capability  without  a  large  software  conmitment. 

3.5  ESTIMATION 

This  section  presents  the  development  of  an  algorithm  designed  to 
estimate  the  module-directed  rating  parameters.  (To  simplify  the  notation, 
these  reduced  parameters  wi 1 1  be  denoted  by  ©  rather  than  ». )  The 
performance  estimation  flow  path  Is  summarized  in  Figure  3.14.  Data  scans  are 
checked  for  sensor  failures  by  the  sensor  validation  algorithm.  If  there  are 
failed  channels,  only  these  are  reconstructed.  Using  the  baseline  model,  the 
residual  measurements  ay  are  computed.  The  values  ay  represent  the 
difference  between  the  observed  measurements  y  and  the  values  y  which  are 
the  predicted  values  for  a  nominal  engine.  This  residual  vector  is  passed  to 
the  estimation  routine  which  produces  an  estimate  «  of  the  module-directed 
rating  parameters.  The  covariance  of  the  estimates  are  updated  and  the 
process  repeated  until  the  estimate  has  converged. 

The  formal  development  of  a  QLR  model  for  engine  performance  culminates 
in  an  easily  linearized  equation  (Eq.  (3.3))  which  relates  the  sensitivity  of 
the  sensor  outputs  to  fault  parameter  variations,  disturbances,  and  Instrument 
effects. 

ay  »  Ha«  +  v  (3.3) 

The  processing  of  measurements  to  derive  accurate  estimates  of  the 
parameter  values  is  the  function  of  the  filtering  algorithm.  The  precise 
algorithm  used  to  filter  the  data  is  strongly  influenced  by  the  type. 
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frequency,  and  accuracy  of  the  measurements.  The  processing  environment, 
operating  scenario,  and  data  interfaces  also  impact  this  procedure.  Several 
different  methods  are  outlined  below  and  a  routine  that  has  been  specifically 
developed  for  processing  off-line  performance  data  is  presented. 

Suppose  the  problem  is  approached  for  the  solution  of  Eq.  (3.3)  by 
inverting  the  measurement  matrix,  H,  i.e. 

ae  -  H”1  ay  (3.4) 

Direct  inversion  of  H  is  possible  only  when  the  number  of  parameters 
equals  the  number  of  measurements.  It  is  usually  possible  to  formulate  the 
model  so  this  condition  is  met.  However,  a  more  subtle  numerical  effect  is 
presented  in  Eq.  (3.4).  During  system  development,  the  error  sources,  v, 
have  been  maintained  at  an  acceptably  low  level,  but  their  effect  on  the 
parameter  estimates  may  not  be  small.  This  property  can  be  quantified  by  the 
condition  number  of  H.  The  condition  number  is  defined  as  the  ratio  of  the 
maximum  to  minimum  eigenvalue  of  H,  or 

”(H)-,o9teS!  (3-5) 

where  x(H)  is  the  modulus  (magnitude)  of  an  eigenvalue  of  H. 

Intuitively,  it  represents  the  magnification  possible  in  matrix 
multiplication.  For  example,  a  matrix  H  with  condition  number 
3  could  conceivably  magnify  a  0.1  percent  sensor  error  into  a 
100  percent  error  in  a  parameter  estimate. 

Before  considering  this  effect  further,  the  inversion  in  Eq. 

(3.4)  can  be  generalized  to  include  the  case  when  the  number  of 
parameters  is  less  than  the  number  of  measurements  as  follows: 

ae  «  (HTH)_1  HTay  (3.6) 

This  reduces  to  Eq.  (3.4)  if  H  is  square  and  invertible.  Equation  (3.6)  is 
the  least-square  (LS)  solution  to  Eq.  (3.3).  If  v  is  considered  a  random 
noise  process  (e.g.,  Gaussian,  zero  mean,  or  N(0,R),  then  its  covariance  is 
written: 

cov(rv)  -  rRrT  (3.7) 
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The  LS  Inverse  (Eq.  (3.6))  can  be  modified  to  form  the  weighted  IS 
estimate  within  the  statistical  framework  as  follows: 

ae  .  (HT  rV^r1  HT  V1  y  (3.8) 

Using  Eqs.  (3.7)  and  (3.8) ,  the  uncertainty  In  the  parameter  estimate  caused 
by  the  noise  can  be  written  as  follows: 

cov(ae)  -  (HT  R  TH)-1  (3.9) 

The  matrix  (HT  R  TH)-1  is  termed  the  dispersion  of  the  estimator 

0  .  (HTrRrTH)'1  (3.10) 

The  information  matrix  for  this  estimate  Is  defined  as  the  Inverse  of  the 
dispersion,  or 

M  .  D"1  (3.11) 

Intuitively,  If  M  is  "large,"  the  estimation  error  covariance  will  be 
small.  The  size  of  M  can  be  specified,  in  part,  by  its  condition  number. 

The  LS  estimation  process  that  arises  from  considering  v  a  Gaussian, 
zero  mean  error  source  is  weighted  least  squares  (WLS).  The  formula  for  the 
WLS  estimate  is  as  follows: 

ao  -  M“1HTR"1ay  (3.12) 

This  estimator  produces  the  maximum  likelihood  or  highest  probability  value 
for  ae  given  a  single  set  of  measurements  and  assuming  a  known  Gaussian 
error. 

The  estimator  In  Eq.  (3.12)  is  used  as  the  basis  for  a  snapshot  estimator 
in  current  GPA  algorithms.  A  number  of  technical  Issues  must  be  resolved 
before  accurate  results  can  be  obtained.  Some  important  problems  are  bias 
levels  in  the  sensors,  errors  in  measuring  the  operating  point,  too  many 
parameters  to  estimate,  and  poorly  conditioned  information  matrices. 

The  WLS  estimator  addresses  the  snapshot  processing  problem.  The 
simplest  filtering  scenario  employs  sequential  processing.  Here,  a 
measurement  is  available  for  processing  once.  Prior  Information  about  the 
parameters  may  be  available  and  include  the  last  estimates  and  their 
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covariances.  The  measurement  Is  processed,  the  parameter  estimates  updated, 
and  the  data  discarded.  This  scenario  Is  common  in  on-line  data  processing. 

The  WLS  form  can  be  extended  to  sequential  filtering.  If  the  noise  statistics 
are  known,  the  resulting  algorithm  Is  known  as  the  Kalman  filter  [27]. 

The  Important  advantage  of  this  processing  scenario  concerns  the  noise 
attenuation  properties  of  the  estimator.  This  may  be  illustrated  using  the 
WLS  information  matrix  defined  in  Eq.  (3.11).  It  can  be  shown  that  for  N 
groups  of  data,  the  resulting  WLS  dispersion  can  be  approximated  by  the 
following  expression: 

'  N  1-1 

D  -  EM,  (3.13) 

Li-1  \ 

where  is  the  information  matrix  for  the  ith  set  of  data.  Thus,  the 
matrix  M  measures  the  accumulation  of  information  about  the  parameters.  The 
obvious  Implication  is  that,  in  general,  the  more  data  used,  the  more  accurate 
the  parameter  estimates.  Also, 

Mi  *  Mj  (3.14) 

i.e.,  if  different  operating  points  are  chosen  for  data  acquisition,  it  is 
possible  that  the  condition  number  of  the  net  information  matrix  will  be 
smaller  than  the  individual  terms.  Physically,  this  represents  the 
combination  of  Information  about  different  parameters  at  different  flight 
points.  Stated  another  way,  it  is  possible  that  more  parameters  than 
measurements  can  be  estimated.  When  this  is  the  case,  important  sensor  error 
parameters  can  be  Included  in  the  estimator  to  Improve  overall  accuracy. 

This  filter  produces  accurate  results  when  (1)  the  parameter  values  are 
constant  and  (2)  the  error  covariance  is  stationary  and  white.  There  is  no 
"check"  of  the  actual  accuracy  from  an  on-line  evaluation.  Also,  as  the 
number  of  data  points  becomes  large,  the  estimator  tends  to  be  "oblivious"  to 
new  Information  due  to  the  large  certainty  attached  to  the  prior  parameter 
estimates. 

Snapshot  and  sequential  processing  have  been  discussed.  The  more 
appropriate  scenario  for  TCM  involves  repetitive  processing  of  a  group  of  data 
points.  This  method  is  often  defined  as  off-line  and  is  shown  schematically 
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in  Figure  3.15,  Starting  with  prior  estimates  and  statistics  of  the 
parameters,  a  group  of  data  points  is  iteratively  used  in  the  calculation. 

A;ter  processing  is  comply'.  ,  the  data  are  discarded  end  the  updated 
estimate*  and  statistics  are  stored. 

An  algorithm  has  been  oeveloped  for  the  data  processing  scenario 
described  above  The  measurement  equation  can  be  written  as  follows: 

ay  -  H \ a , u ) a©  +  v  (3.15) 


where  v  is  a  normal,  Gau^iau  sensor  and  disturbance  vector  with 

Specific  elements  of  the  y,  «,  and  v  vector  have  been  discussed  in  the 
previous  sections.  The  best  estimate  of  the  parameters  e,  for  e.  set  of 
measurements  can  be  found  frum  a  minimization  of  the  likelihood  function  given 
as  follows  [28]: 

y 

0  -  z  (ay(k)  -  H(x.u)  d)TR~1(Ay(k)  -  H(xtu)e) 

1«1 


*  (.  -  ,arl  rh*  -  .u) 


where  tl  c  last  term  represents  the  a  prior  t  covariance  of  the  parameter 
estimates.  The  necessary  conditions  for  a  minima  are  given  as  follows: 
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and  at  each  step,  R  can  be  calculated  as  follows: 
R  -  ^  £  (ay1-H(x1,u)e1)(ayi-H{x1,u)ei) ) 


and 
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The  calculation  procedure  uses  Iterations  through  the  data  to  arrive  at  a 
consistent  optimal  estimate.  The  estimate  Is  then  used  to  update  the  sensor 
variance  and  parameter  uncertainty  levels  for  the  data  record.  Prior 
Information,  M0,  on  the  parameter  accuracy  is  stored  along  with  the 
estimates  of  the  sensor  noise  level  and  the  parameter  estimates  themselves. 

The  procedure  Is  quite  compatible  with  the  processing  scenario.  If  a 
maintenance  action  or  sensor  replacement  has  been  performed  between  data 
records,  the  parameter  covariance  and  sensor  noise  levels  can  be  Increased  to 
make  the  filter  respond  to  the  new  information.  The  parameter  estimates  and 
sensor  noise  levels  are  also  used  In  the  sensor  diagnostic  routines  to 
determine  the  threshold  levels  to  validate  new  sensor  measurements. 


3.6  TRENDING 

The  parameter  estimation  algorithm  produces  time-varying  estimates  of 
engine/component  module  health.  It  Is  desired  to  correlate  these  estimates 
with  engine  maintenance  actions.  However,  since  the  module-directed  rating 
parameter  estimates  are  noisy  estimates  (l.e.,  not  known  with  certainty)  It  Is 
useful  to  to  trend  these  estimates.  This  section  describes  the  development  of 
a  trending  algorithm. 

The  trending  routine  fits  a  piecewise  linear  function  to  data.  The 
procedure  is  based  on  the  assumption  that  an  engine  health  parameter  will 
decrease  linearly  over  time  until  a  maintenance  action  occurs.  Ideally,  at 
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that  point,  the  engine  health  parameter  will  Increase  to  some  value.  The  jump 
reflects  the  Improved  condition  of  the  engine  (or  component  module).  Linear 
deterioration  resumes  until  another  maintenance  action  occurs,  and  the  cycle 
Is  repeated.  The  routine  attempts  to  find  the  linear  trends  and  jump  polnt(s) 
in  the  noisy  data. 

The  general  approach  followed  by  this  routine  is  to  determine  potential 
jump  points  using  a  minimum  sum  of  squares  criterion.  The  best  jump  points 
are  then  selected  from  the  potential  ones.  Least-squares  line  segments  are 
fitted  between  the  selected  jump  points.  The  details  of  this  approach  will 
be  described  next. 

The  Input  to  the  algorithm  Is  a  set  of  N  data  points,  denoted 
(x-| ,y^ ) ,  M,2,...,N.  Normally,  the  x  values  will  represent  total 
operating  time  of  the  engine  and  the  y  values  will  represent  an  engine  or 
module  rating  parameter.  The  first  step  is  to  sort  the  data  so  that  x^  £ 
x.|+i  for  all  1.  Then  the  best  single  line  Is  fitted  to  the  data.  This 
line  can  be  written  as  y-mx  +  b. 

Associated  with  this  line  Is  a  sum  of  squares,  SS(0),  defined  by 

ss(0)  -  s  (^  -  yi)2 

1*1 

(see  Figure  3.16) . 

Next,  two  line  segments  are  fit  to  the  data  to  determine  If  there  Is  a 
significant  Improvement  In  the  total  sum  of  squares.  This  Is  done  by  choosing 
a  J  between  1  and  N,  and  then  fitting  line  segments  to  the  data  from 
x^  to  Xj  and  another  line  segment  from  Xj+j  to  xN  (see  Figure 
3.17).  As  above,  there  Is  a  total  residual  sum  of  squares  associated  with  the 
line  segments,  and  this  total  depends  on  J.  J  Is  varied  from  l  to  N-2, 
and  J*  Is  set  equal  to  the  J  which  minimizes  the  total  sum  of  squares  (see 
Figure  3.18).  This  total  Is  denoted  SS(’),  the  minimum  sum  of  squares  with 
onu  jump.  This  procedure,  called  FiNUJUMP,  forms  the  basis  of  the  entire 
trending  routine.  F I ND JUMP ( I,J,K)  returns  In  K  the  best  jump  point 
between  Xj  and  Xj.  On  the  first  call  to  FINDJUMP,  J-l,  0-N  and  the 
nrocedure  returns  with  K«J*. 
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BEST  LINES  FROM  Xm=6.6  TO  XCJi=l6.e  fiMB  FROM  X<J+li=16.S  TO  XtHJ 


If  SS(1)  Is  not  significantly  less  than  SS(0),  the  trending  routine 
returns  the  best  single  line  and  halts.  Otherwise,  SS(2),  the  (near) 
optimal  sum  of  squares  with  two  jumps  (three  line  segments).  Is  computed.  In 
order  to  compute  SS(2),  It  Is  necessary  to  determine  the  best  two  jump 
points,  and  J2.  That  is,  the  problem  Is  to  find  0^  and 
J2  which  minimize  the  following  sum: 


where  y^  Is  the  best  line  from  to  Xj^,  y^  Is  the  best 
line  from  xJ+1  to  xJ2,  etc.  There  are  N ( N— 1 ) / 2  possible  choices  of 
<3}  and  J2.  For  large  N,  enumerating  all  possibilities  Is  a 
computationally  tractable  problem.  Instead,  up  to  15  candidate  jump  points 
are  determined.  Then,  all  pairs  of  these  are  enumerated  until  the  two  are 
found  which  minimize  Eq.  (3.16). 

The  15  (or  less)  candidate  jump  points  are  determined  as  follows.  It  is 
assumed  that  0*,  these  best  jump  point  between  x1  and  xN,  has  been 
determined.  Cl-J*  is  the  first  candidate.  The  second  and  third  candidates 
are  determined  by  the  FINDJUMP  routine;  FINDJUMP  (1,  Cl,  C2),  FINDJUMP  (Cl+1, 
N,  C3)  return  two  more  candidates,  C2  and  C3.  Similarly,  the  fourth  candidate 
is  determined  from  FINDJUMP  (1,  C2,  C4),  etc.  (see  Figure  3.19).  Fewer  than 
15  candidates  are  determined  if  N  is  small.  Only  these  candidates  *tre 
searched  for  the  best  two  jump  ponts.  These  are  denoted  jJ  and  j£ 

(see  Figure  3.20),  Then,  SS(2)  is  the  sum  of  square  given  In  Eq.  (3.16) 
for  and  d2«J2> 

If  SS(2)  is  not  significantly  less  than  SS(1),  the  trending  routine 
returns  the  best  two  line  segments  (corresponding  to  the  jump  at  J*)  and 
halts.  Otherwise,  S$(3)  is  determined  by  considering  all  triples  of  jumps 
among  the  15  candidates.  Table  3,11  lists  SS( 1 ) ,  i-0,1,2,3  for  the  example 


Figure  3.20  Trending  Example 


Table  3.11 


Sum  Of  Squares  In  Example 
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2 

3 

N— 150 


SS(I) 

553.14 

348.53 

134.03 

124.15 


Optimal  number  of  jumps  occur  at  I«2 
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shown  in  Figures  3.16  through  3.20.  Figure  3.20  shows  the  final  trending 
result. 

The  trending  routine  flowchart  is  summarized  in  Figure  3.21. 

Gaps  in  the  data  do  not  present  any  difficulty  to  the  trending  routine 
(see  Figure  3.22).  It  is  also  possible  to  specify  in  advance  the  number  of 
jumps  desired.  For  example,  even  if  there  are  two  jumps  corresponding  to 
engine  maintenance  actions,  specifying  no  jumps  will  show  if  there  is  a 
long-term  linear  decline  (as  in  Figure  3.16).  Additional  sample  results  are 
shown  in  Figures  3.23  through  3.2S. 


NJ  -  NUMBER  OF  JUMPS 

MAXNJ  -  MAXIMUM  NUMBER  OF  JUMPS  (<15) 

SS(I)  -  TOTAL  SUM  OF  SQUARES  WITH  I  JUMPS 

THRSH  -  THRESHOLD  VALUES  (TYPICALLY  THRSH  -  0.75) 

STEP  1.  SORT  THE  DATA  (BY  x  VALUES)  NJ  4  0. 

STEP  2.  COMPUTE  SS(O)  AND  BEST  SINGLE  LINE  (NO  JUMPS). 

STEP  3.  COMPUTE  SS(1)  AND  BEST  TWO-LINE  SEGMENTS  (1  JUMP). 

STEP  4.  IF  SS(1)/SS(0)  >  THRSH,  GO  TO  STEP  10. 

STEP  5.  DETERMINE  UP  TO  15  CANDIDATE  JUMP  POINTS. 

STEP  6.  NJ  4  NJ+1.  IF  NJ  >  MAXNJ,  GO  TO  STEP  10. 

STEP  7.  COMPUTE  SS(NJ+1)  AND  BEST  NJ+2  LINE  SEGMENTS 

(NJ+1  JUMPS)  FROM  THE  CANDIDATE  JUMPS. 

STEP  8.  IF  SS(NJ+1)/SS(NJ)  >  THRSH,  GO  TO  STEP  10. 

STEP  9.  GO  TO  STEP  6. 

STEP  10.  OUTPUT  BEST  NJ+1  LINE  SEGMENTS  (NJ  JUMPS).  STOP. 


Figure  3.21  Flowchart  For  The  Trending  Routine 
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gure  3.22  Sample  Trending  Routine  Result:  Data  With  A  Gap  in  X  Values 


Figure  3.23  Sample  Trending  Routine  Result:  Data  With  Three  Jumps 


ENGINE  PROFILE 
MYRTLE  BENCH  NFB 


Figure  3.25  Sample  Trending  Result 


IV.  INTEGRATION  WITH  MAINTENANCE  MANAGEMENT 


4.1  INTRODUCTION 

The  key  to  the  effectiveness  of  an  automated  turbine  engine  monitoring 
system  Is  Its  Incorporation  In  the  maintenance/  logistics  framework  of  the  Air 
Force.  Chapter  IV  presents  the  requirements  for  Integration  of  a  generic  TEMS 
with  the  Air  Force  maintenance  environment.  Requirements  are  outlined  In 
terms  of  function  and  keyed  to  specific  software  capabilities.  Background  on 
the  maintenance  organization  Is  provided  and  the  maintenance  management 
philosophy  Is  discussed. 

Motivating  Factors  for  Automated  Engine  Monitoring 


The  factors  which  drive  the  need  for  and  the  structure  of  an  Integrated 
engine  monitoring  system  are  two-fold: 

(1)  minimization  of  operations  and  support  costs  of  the  Air  Force 
engine  Inventory  [30];  and 

(2)  maximization  of  the  availability  of  engines  to  support  Air 
Force  peacetime  force  capability  and/or  wartime  operations 
[31,32]. 

While  these  requirements  have  always  been  recognized  by  military  and  civilian 
organizations,  it  is  within  the  past  two  decades  that  the  complexity  of 
meeting  these  needs  has  been  most  urgently  realized.  The  events  which  have 
most  recently  affected  this  realization  are: 

•  introduction  of  increasingly  more  complex  engine  designs  (for 
higher  performance  aircraft)  Into  the  Inventory  [31] 

•  increasing  rate  of  growth  of  the  Inventory  as  older  engines  (J79, 
TF41,  TF30)  are  retained,  and  large  numbers  of  the  new  engines 
supporting  advanced  aircraft  (A-10,  F-15,  F-16)  are  produced  in 
large  quantity  [33] 

•  rising  costs  of  operation  and  support,  in  both  personnel  and 
material  [3C] 


The  Air  Force  is  responding  to  these  events  in  several  ways: 

•  introduction  of  new  maintenance  concepts  [34,35] 

•  development  and  evaluation  of  two  new  engine  monitoring  systems 

•  implementation  of  a  comprehensive  engine  management  system  to 
support  both  home  base  and  global  operations  [33,36]. 

Figure  4.1  illustrates  the  primary  motivational  elements  for  integrated  engine 
monitoring  capability. 

4.2  REQUIREMENTS  BACKGROUND 

4.2.1  Management  Organization 

The  Air  Force  engine  management  structure  consists  of  three  levels: 
base,  depot,  and  command.  Figure  4.2  illustrates  the  management  organization. 

The  first  level  is  the  operating  base.  It  consists  of  the  flight  line 
and  the  Jet  Engine  Intermediate  Maintenance  (OEIM)  facility.  The  Tactical  Air 
Command  (TAC),  which  was  the  primary  focus  of  this  study,  operates  under  a 
production-oriented  maintenance  organization  (POMO).  This  base  management 
structure  differs  from  the  other  commands  in  that  various  propulsion 
speci; lists  have  been  removed  from  the  shop  and  assigned  to  the  flight  line, 
allowing  for  a  more  flexible  utilization  of .manpower. 

Under  the  POMO,  the  flight  line  Is  manned  by  members  of  the  Aircraft 
Generation  Squadron  (AGS).  The  primary  mission  of  the  AGS  Is  to  support  a 
wing's  aircraft  sortie  schedule.  They  support  installed  engine  maintenance. 
The  Component  Repair  Squadron  (CRS)  operate  the  JEIM  facility  and  perform  the 
uninstalled  engine  repair.  Base-lev^ 1  personnel  are  responsible  for 
specifying  engine  trim  requirements,  diagnosing  faults,  directing  engine 
removals,  and  troubleshooting  engine  discrepancies.  Based  on  factors  such  as 
type  and  extent  of  failure,  estimated  repair  time,  ability  to  Isolate  failure 
source  accurately,  and  local  availability  of  resources,  the  decision  Is  made 
to  perform  flight  line  maintenance  on  line  replaceable  units  (LRU  level),  OEIM 
repair,  or  transport  the  engine  (or  modules/subassemblies)  to  a  centralized 
depot  [37,38]. 
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Figure  4.1  Driving  Elements  for  the  Development  of  an 
Integrated  Engine  Monitoring  Capability 
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The  Air  Logistics  Center  (ALC),  the  second  echelon,  operates  centralized 
depots  for  major  repair.  A  team  at  each  ALC  Is  responsible  for  specifying  the 
most  economical  level  of  repair  necessary  to  return  engines  and  modules  to 
serviceable  condition.  Individuals  assigned  to  an  engine  type  monitor  overall 
fleet  health  and  process  historical  data  to  forecast  failures  and  schedule 
removals  over  a  two-year  period.  They  use  this  actuarial  data  to  predict 
workloads,  spare  parts  procurement,  and  to  calculate  stockage  objectives  for 
both  depot  and  base  supply.  Maintenance  engineering  staff  at  the  ALC  are 
responsible  for  anticipating  and  identifying  maintenance  problems.  Based  on 
their  analysis,  they  recommend  alternative  approaches  and  procedures  for 
engine  operation  and  support  [37]. 

The  third  level  of  the  engine  management  structure,  the  Headquarters  Air 
Force  Logistics  Command  (HQAFLC),  Is  responsible  for  establishing  policy  for 
Inventory  control  and  maintenance  procedures.  They  develop  the  software  and 
mathematical  models  used  throughout  the  Air  Force  to  perform  logistical 
analyses  and  support. 

In  addition  to  the  line  maintenance  and  logistics  organization  described 
above,  the  operational  commands  provide  parallel  management  organization.  The 
engine  managers  located  at  each  of  the  major  commands  (MAJCOM)  are  concerned 
with  monitoring  fleet  performance.  They  determine  mission  capability  and 
readiness  posture  of  each  base  and  the  overall  fleet  in  their  respective 
command.  Like  their  counterparts  at  the  ALC's,  MAJCOM  managers  also 
participate  in  the  prediction  of  workloads,  spare  parts  procurement,  and  the 
calculation  of  stockage  objectives  [38,39], 

A  comprehensive  engine  management  system  currently  under  development  Is 
puiHonce  of  the  Air  Force's  commitment  to  Improved  engine  management  within  a 
structured  organizational  framework.  The  proposed  system  will  link  various 
users  in  the  Air  Force  engine  maintenance/logistics  process  (see  Figure  4.3). 

4.2.2  Engine  Maintenance  Philosophy 

Air  Force  engine  maintenance  policy  for  the  1980s  has  been  defined  using 
the  principles  of  reliability  centered  maintenance  (RCM).  RCM  stemmed  from  a 
need  to  define  an  effective  strategy  for  minimizing  aircraft  and  engine 


93 


Figure  4.3  Integrated  Maintenance/Logistics  Network 


operation  and  support  (OaS)  costs.  Its  objective  is  the  specification  cf  a 
maintenance  program  that  "achieves  inherent  safety  and  reliability 
capabilities  at  minimum  cost"  [34]. 

The  adoption  of  modular  engine  design  impacts  engine  operation  and 
support.  New  engines  consist  of  several  modules  and  minor  external 
accessories  (e.g.  casing,  wiring,  plumbing,  etc.),  which  can  be  easily  removed 
from  the  engine  for  maintenance.  With  an  adequate  local  inventory  of  spare 
modules,  this  procedure  can  minimize  engine  down  time  and  improve 
availability.  The  successful  exploitation  of  modular  maintenance  requires  the 
ability  to  isolate  engine  faults  to  the  modular  level  [31,32]. 

Sophisticated  new  engine  design  has,  therefore,  imposed  requirements  on 
maintenance  procedures  to: 

•  acquire  and  apply  diagnostic  Indicators  to  support  more  complex 
design 

•  monitor  life  usage  on  a  module/component  rather  than  an  engine 
basis 

•  enhance  fault  detection  and  isolation  capability  to  the  module 
level  at  the  flight  line  as  well  as  the  intermediate  and  depot 
levels. 

The  concept  of  an  MOT  for  an  entire  engine  has  been  replaced  by  hard  time 
limits  for  critical  engine  components  whose  failure  modes  are  characterized  by 
low-cycle  fatigue,  thermal  fatigue,  or  stress  rupture.  RCM  requires  the 
collection  of  accurate  life  usage  data  for  all  hard  time  components  so  that 
engine  removals  can  be  scheduled.  The  monitoring  of  equivalent  age  (i.e. 
operating  time,  LCF  counts,  or  time  at  or  above  certain  temperature  levels)  is 
a  formidable  data  collection  and  documentation  task  because  an  engine  can 
typically  have  upwards  of  100  life-limited  components  [34], 

The  major  objective  of  RCM  is  to  eliminate  the  process  of  complete 
equipment  overhaul.  Under  the  previous  overhaul  concept,  at  a  set  operating 
age  an  engine  was  removed  and  transferred  to  a  depot  facility  for  complete 
teardown,  inspection,  component  replacement/refurbishment,  and  reassembly  In 
accordance  with  standard  technical  orders.  When  the  engine  was  returned  to 
service,  the  operating  age  was  reset  to  zero  on  the  assumption  that  the 
overhaul  had  returned  the  engine  to  a  state  comparable  to  its  original 
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condition.  Not  only  is  this  expensive,  but  there  is  evidence  that  some  engine 
failure  phenomenon  are  not  directly  age  related  across  the  entire  engine 
population. 

RCM  is  actually  a  planning  process  that  identifies  the  “best"  (i.e. 
cost-effective,  safety-oriented)  maintenance  procedure  for  a  unit,  its  major 
subassemblies,  and  components.  The  exact  specification  of  maintenance  is 
based  on  engine  condition  and  is  called  on-condition  maintenance  (QCM).  The 
procedure  specification  is  dependent  on  the  unit's  failure  modes  and 
characteristics.  RCM  categorizes  failure  modes  based  on  an  ability  to 
identify  incipient  failure.  It  is  desirable  although  not  always  feasible  to 
identify  a  reduced  resistance  to  failure.  For  these  failure  modes,  it  is 
advisable  to  identify  life  usage  limits  that  either  direct  component 
replacement  or  establish  fixed  interval  periodic  maintenance.  Figure  4.4  is  a 
flow  diagram  depicting  the  development  of  an  RCM  maintenance  plan. 

For  those  engine  failure  modes  that  can  be  classified  by  condition 
monitoring,  it  is  necessary  to  establish  installed  engine  inspection 
procedures  (e.g.  borescope)  and  monitoring  techniques  (e.g.  oil  analysis, 
performance  trending)  to  identify  Incipient  failures  in  a  timely  manner. 
Turbine  engine  monitoring  systems  are  obviously  an  important  source  of  both 
condition  data  (diagnostics,  performance)  and  usage  factors  (time,  cycle, 
temperature  time  factors)  [40]. 

Visual  borescope  inspection  and  oil  analyses  are  an  effective  meanr  of 
gathering  a  small  portion  of  the  engine  condition  information.  These 
techniques  are  inadequate,  however,  for  providing  extensive  fault  isolation 
capabilities,  diagnostics,  or  performance  trending.  Development  of  an 
automated  monitoring  capability  appears  to  be  necessary  if  RCM  concepts  to 
be  successfully  and  cost-effectively  applied  to  Air  Force  t-.gine  support.  ii;<* 
next  section  examines  the  management  decisions  associated  nt'.t  RCM  and 
identifies  the  types  of  information  required  at  each  user  level  In  the  engine 
operation  and  support  cycle. 
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Figure  4.4  Development  Process  For  An  RCM  Plan 
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4.2.3  User  Requirements  for  Monitored  Propulsion  Data 


The  user  requirements  for  engine  monitoring  data  are  dependent  upon  the 
management  decisions  implemented  at  eacn  engine  support  level.  The  user 
categories  are: 

•  pilot/flight  crew 

•  flight  line  (AGS) 

•  JEIM  (CRS) 

«  depot 

t  command 

These  users  with  their  respective  information  requirements  determine  the 
data  acquisition  and  processing  requirements,  software  logic,  and  information 
access  capability. 

The  cockpit  level  scenarios  associated  with  engine  support  are  limited  to 
decisions  related  to  mission  abort  and  pilot/crew  safety.  These  decisions 
require  in-flight  information  that  alert  the  pilot  of  a  critical  event  (e.g. 
overtemp,  overspeed)  that  may  impact  an  in-flight  decision.  To  be  effective, 
the  alerts  must  be  displayed  on-exception  and  restricted  to  only  those  that 
specifically  require  the  pilot  to  take  an  action.  Pilot/flight  crew  reported 
discrepancies  or  squawks  have  been  valuable  indicators  of  maintenance 
requirements  (e.g.  out-of-trim,  stall,  flame, out).  Instrumenting  the  cockpit 
with  a  record  option  facilitates  the  collection  of  suspect  diagnostic  data 
that  are  used  in  conjunction  with  the  pilot's  debriefing  report. 

Maintenance  level  scenarios  span  three  user  groups:  flight  line,  JEIM, 
and  depot.  Table  4.1  classifies  some  typical  engine  maintenance  decisions  by 
base  management  level.  At  the  flight  line,  the  AGS  must  make  rapid  go/no-go 
decisions  for  maximum  sortie  capability.  The  detection  of  engine  faults, 
isolation  to  the  LRU  level,  and  the  specification  for  a  maintenance  action  are 
important  flight  line  diagnostic  decisions.  Because  the  trim  pad  is  operated 
by  flight  line  personnel,  trim  decisions  and  procedures  occur  primarily  at 
this  level. 

After  engine  removal,  the  1EIM  controls  the  asset.  In  practice,  both 
flight  line  and  shop  managers  participate  In  the  removal  decision.  Detection 
and  isolation  decisions  are  supported  by  test  cell  troubleshooting.  The 
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Table  4.1 


Typical  Maintenance  Decisions/Scenarios  By  User  Level 


1 

1 

1 


1 


FLIGHT  LINE 

JEIM 

DEPOT 

GO /NO-GO 

X 

TRIM 

X 

FAULT  DETECTION 

X 

X 

REMOVAL 

X 

X 

LRU  ISOLATION 

X 

FAULT  ISOLATION 
(MODULAR  LEVEL) 

X 

X 

MAINTENANCE 

SPECIFICATION 

X 

X 

X 

TRENP  UTOR 

X 

NEAR-TERM  FORECAST 

X 

DEPLOYABLE  ENGINE 
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X 

X 
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maintenance  decision  is  dependent  on  these  results,  historic?  data,  and  local 
resources.  Maintenance  requirements  associated  with  monitored  trends  would  be 
identified  at  the  JEIM  level.  The  decision  to  remove  the  engine  or  perform 
LRU  repair  overlaps  both  maintenance  levels  at  the  base.  Information 
requirements  for  troubleshooting  and  for  preventive  maintenance  performed  at 
this  level  are  shown  in  Tables  4.2  and  4.3  [38,41]. 

Under  RCM,  an  engine  or  module  is  transported  to  the  depot  level  if  the 
base  cannot  Isolate  the  fault,  the  repair  is  beyond  local  capability,  or 
technical  orders  specify  the  return.  Depot  level  maintenance  decisions  are 
currently  made  by  an  OCM  team  that  relies  on  historical  data,  removal 
justification,  and  engine/module  records  [37]. 

Engine  logistics  management  decisions  are  centered  at  the  depot  and 
conmand  level  (see  Table  4.4).  At  the  depot,  the  users  can  be  divided  into 
two  categories,  maintenance  engineering  and  actuarial  support.  Engineering 
staff  is  Involved  in  the  development  of  improved  maintenance  support  for  their 
assigned  engines.  This  requires  the  monitoring  of  fleetwide  engine  health  on 
a  type/model  basis.  They  also  provide  expertise  in  the  identification  of 
reliability  and  maintainability  problems  that  must  be  addressed  by  component 
improvements.  Actuarial  staff  are  involved  in  the  synthesis  and  analysis  of 
engine  removal  data  and  failure  statistics  to  determine  the  procurement  of 
spares  and  the  optimal  distribution  across  the  operating  bases  [42], 

Command  level  engine  management  at  the  major  commands  and  AFLC  are 
concerned  with  a  wide  variety  of  operating  problems  in  the  engine  support 
process.  These  range  from  determining  the  impact  of  the  implementation  of  a 
Component  Improvement  Program  to  the  development  of  logistics  support  models. 
To  address  the  implications  of  these  scenarios  adequately,  engine  managers  and 
logistics  analysts  must  have  access  to  certain  types  of  engine  performance  and 
maintenance  data  on  a  fleetwide  basis  (see  Table  4.5)  [38]. 

4.3  FUNCTIONAL  DESCRIPTIONS  VS.  REQUIREMENTS  DEFINITION 

Data  products  and  information  displays  are  driven  by  operational 
functions  that  must  be  implemented  during  the  development  of  ™  integrated 
monitoring  system.  Design  Issues  Include: 
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Table  4.4 


Logistics  Management  Decision  Scenarios  At  Depot  and  Command  Level 


DEPOT  COMMAND 

DECISION  TYPE 

MAINTENANCE 

ENGINEERING 

ACTUARIAL 

(MAJCOM 

AND  AFLC) 

COMPONENT  IMPROVEMENT 
PROGRAM  (CIP)  SUPPORT 

X 

X 

CIP  IMPACT 

X 

SPARE  PROCUREMENT  AND 
DISTRIBUTION 

X 

X 

FLEETWIDE  READINESS 

X 

MISSION  PERFORMANCE 
ASSESSMENT 

X 

X 

LOGISTICS  SUPPORT 
MODELING 

"" .  . 

X 

DEVELOPMENT  OF  IMPROVED 
MAINTENANCE  SUPPORT 

X 

X 
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Table  4.5 

Information  To  Support  Typical  Command  Level  Engine  Management 


DECIS’ON  TYPE 

ENGINE  REMOVAL/ 
FAILURE  DATA 

SELECTIVE 

MAINTENANCE 

RECORDS 

BASE 

REPAIR 

RATE 

FLEETWIDE 

STATUS 

GROSS 

HEALTH 

TREND 

MISSION 

SCENARIOS 

COMPONENT  IMPROVEMENT 

PROGRAM  (CIP)  SUPPORT 

X 

X 

X 

MIP  IMPACT 

X 

X 

SPARE  PROCUREMENT  AND 
DISTRIBUTION 

X 

X 

X 

ELEETWIDE  READINESS 

X 

X 

X 

X 

X 

MISSION  PERFORMANCE 

ASSESSMENT 

X 

X 

LOGISTICS  SUPPORT  MODELING 

X 

X 

X 

X 

DEVELOPMENT  OF  IMPROVED 
MAINTENANCE  SUPPORT 

X 

X 
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(1)  data  Items; 

(2)  data  format; 

(3)  access/inquiry; 

(а)  storage/archive; 

(5)  software  logic;  and 

(б)  Interfaces. 

Data  items  are  derived  from  subsystems  (e.g.,  TEMS,  SOAP,  MDCS).  The 
formation  of  displays  requires  software  logic  (e.g.,  diagnostics,  trending, 
etc.)  to  translate  subsystem  data  to  readily  accessed  management  information. 

Integrated  requirements  are  based  on  the  functional  capabilities  of  the 
monitoring  and  management  system,  'fable  4.6  illustrates  how  the  Important 
elements  of  the  functional  description  Irpact  key  requirements  for  data 
acquisition/  Interface,  software,  and  hardware  Implementation.  The  data  items 
identified  during  the  survey  analysis  lead  to  development  of  the  data 
acquisition  and  interface  requirements.  These  are  most  Important  at  the  base 
level  where  the  TEMS  data  (and  most  other  data)  originates.  System  operating 
functions  defined  by  data  acquisition  and  Interface  definitions  drive  the 
software  logic  definition  and  processing  hardware  configuration.  Specific 
requirement  definitions  are  presented  in  subsequent  sections. 

4.4  DATA  ITEM  INTERFACE  RECOMMENDATION 

Required  data  items  established  during  the  Phase  I  survey  are  listed  in 
Table  4.7.  This  Information  is  required  by  base  personnel  to  perform 
maintenance  functions.  The  data  source  for  each  is  shown  with  the 
corresponding  Air  Force  procedure.  It  should  be  pointed  out  that  several 
Items  exist  In  hard  copy  or  In  the  base  computer,  or  both  depending  on  the 
base  implementation.  It  is  assumed  that  these  Items  will  become  resident 
within  the  integrated  base  level  system.  The  data  Items  are  grouped  by  source 
subsystem  in  Table  4.8.  Each  subsystem  and  Interface  requirement  is  described 
in  more  detail  below. 
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Table  4.6 


Relationship  Between  Functional  Definition  and  System 

Requirements 


^requirement 
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Q.  L. 
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AIRBORNE 
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LOCAL 
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1 — 
I-* 

ii 

If 

DATA/ INFORMATION: 

■ 

■ 

■ 
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B 

X 

X 
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X 

X 
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X 

X 

■ 

X 
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B 

■ 

DIAGNOSTICS 

X 

X 

X 

X 
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X 

X 

X 

X 

X 

X 
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X 

X 

X 

X 

X 

X 
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X 

■ 

X 

X 

X 

X 

X 

X 
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X 

X 

X 

X 

X 

X 
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B 

■ 

X 

X 

X 

X 

X 
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■ 

■ 

■ 

X 

X 

X 
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X 
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■ 
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Table  4.7 


Survey-Determined  Required  Data  Items 
( Source/Documentation) 


DATA  ITEM 

SOURCE 

PROCEDURE  REFERENCE 

COMMENT 

PERFORMANCE 

TEMS 

NONE 

DEPENOENENT  ON  ENGINE  AND 

LEVEL  AF  TEMS  IMPLEMENTATION 

TIME/CYCLES 

"EHS 

NONE 

PROCEDURES  DEVELOPED  FOR  EACH 
SYSTEM 

EHR/ETTR 

T. 0.-00-20-5-1 

AFTO  93/AFTO  25 

LEVEL  I  TEMS 

DATA  SOURCE 

VIBRATION 

TEMS 

NONE 

IN-FLIGHT  EVENT  AND  GROUND  RUN 

GRGUNO  RUN 

ENGINE  T.O. 

SOAP 

HARD  COPY 

OR  HARD  BASE 

T.0.42B-1 (PROCEDURE) 
T.O. 33-1-37  (MANUAL) 

IMPLEMENTATION  CURRENTLY 
DEPENDENT  ON  BASE  PROCEDURE 

BORESCOPE 

ENGINE  LOG 

T.O. -00-20-5-1 

AFTO  95 

LOCATION  OF  LOG: 

-  INSTALLED  -  DCM  OFFICE 

-  SHOP  -  JEIM  OFFICE 

-  DEPOT  -  DEPOT  OFFICE 

MAINTENANCE 

HISTORY 

ENGINE  LOG 

BASE  COMPUTER 
MOCS 

T.O. -00-20-5-1 /AFTO  95 

AFM  66-267 
( DSC :G001) /AFTO  349 

SEE  BORESCOPE 

ALL  MAINTENANCE  ENTRIES 

AGAINST  -6  WUC 

ENGINE  BUILD 

MMICS  TRE 

AFM  66-378 
(OSO  G073) 

REPLACES  AFTO  7B1E 

ENGINE  STATUS 

BASE  COMPUTER 

AFM  400-1 

AFTO  1534 

INPUT  TO  0024  AT  DEPOT 

NOT  AVAILABLE  AT  BASE 
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Table  4.7  (Continued) 


DATA  ITEM 

SOURCE 

PROCEDURE  REFERENCE 

COWENT 

REPAIR  STATUS 

MMICS/TCTO 

JEIM  SHOP 

AFM  66-278 

BASE  STANDARDS  -  DCM 

REQUIRES  SEVERAL  MMCS  TRICS 

PERCENT  COMPLETE  OR  MMH 

BACKLOG  DESIRABLE 

FLYING 

SCHEDULE 


MANUAL  OR  BASE 
COMPUTER 


8ASE-DEPEN0ENT 


HILL  BE  AUTOMATED  IN 
THE  FUTURE 


Table  4.8 


Data  Source  Subsystems 


DATA  SOURCE 

DATA  ITEM 

IMPLEMENTATION 

AUTOMATED  TEMS 

PERFORMANCE 

TIME/CYCLES 

VIBRATION  (OPTIONAL) 

DPU/DDU 

BASE  COMPUTER 

STATUS 

MDCS 

BUILD 

FLYING  SCHEDULE 

ENGINE  STATUS 

SOAP  (BASE  OPTION) 

PARTS  TRACKING 

MMICS 

SHOP  (MANUAL) 

80RESC0PE 

REPAIR  STATUS 
MAINTENANCE  HISTORY 

SOAP  (BA.SE  OPTION) 

ENGINE  LOG/AFTO  95 

CENTRAL/ DEPOT 

ENGINE  RECORDS 

TCTO  INFORMATION 

MMICS  TAPE 
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4.4.1  TEMS  Implements  ion  Requirements 

One  important  source  of  maintenance  data  is  the  automated  TEMS.  The 
sophistication  of  the  TEMS  hardware  ranger  rom  automatic  logging  of  usage 
counts  to  complex  diagnostic/trim/troubleshooting  equipment  su:h  as  the 
F100/EDS  or  TF34/TEMS.  Recommendations  for  implementation  of  “he  automated 
TEMS  consistent  with  maintenance  information  requirements  and  operational 
procedures  are  summarized  below. 

(1)  The  on-board  instrumentation  (e.g.,  sensors,  processor,  multiplexer) 
and  acquisition  logic  (e.g.,  sampling  rate,  data  windows)  impact  the  accuracy 
of  measured  data.  The  engine  sensors  are  sources  for  performance  data  and  for 
flight-line  diagnostic  inputs.  Time  and  temperature  are  recorded  to  track 
engine  life  usage.  The  sensor  complement  and  accuracy  impact  the  overall 
capability  of  the  performance  monitoria*.  Table  4.S  lists  important  elements 
in  the  trade-offs  inherent  in  data  acquisition  and  instrumentation  systems. 

(2)  On-board  and  off-board  software  must  account  for  measurement  error 
sources  that  are  induced  by  engine  disequilibrium  (process  noise),  sensor 
noise,  and  probe  dynamics.  These  methods  improve  the  overall  quality  and 
accuracy  of  the  performance  estimates  derived  from  the  raw  measurements. 

(3)  An  important  consideration  in  processing  automatically  acquired  data 
is  the  detection  and  disposal  of  data  scans  that  include  failed  or 
disconnected  channels.  In  practical  operation,  input  channels  may  remain 
failed  for  long  periods  because  a  maintenance  opportunity  has  not  arisen.  A 
procedure  for  detection  and  reconstruction  is  clearly  required.  It  should 
establish  whether  current  values  are  consistent  with  previous  measurements. 
Inconsistent  data  channels  should  be  flagged  to  the  user  as  sensor  faults. 

(4)  On-board  data  storage  and  processor  capabilities  must  accommodate 
aircraft  mission  and  sortie  rate  for  command-specific  operating  scenarios. 
Based  on  the  specific  engine  and  command  implementation,  trade-offs  should  be 
made  between  the  storage  and  processor  retirements.  For  example,  if  data 
compression  algorithms  are  identified  as  practically  via'a’.e,  it  might  be  cost 
effective  to  enhance  on-board  processor  software  to  reduce  on-board  data 
storage. 
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Table  4.9 


Sensor  Requirements  vs.  Capability  for  Automated  TEMS 


INCREASING 

COMPLEXITY 


MAJOR  SENSOR  ADDITION 

ADDITIONAL  CAPABILITY 

TIME 

MANUAL  CYCLES 

CORE  SPEED 

LCF  COUNTS 

TURBINE  TEMPERATURE 

HOT  SECTION  TIME 

VIBRATION  ACCELEROMETER 

VIBRATION  LEVEL/EVENTS 

AMBIENT  PRESSURE 

AMBIENT/ FAN  TEMPERATURE 
FAN  SPEED 

OVERALL  PERFORMANCE 
CHECKING/TRENDING/EVENTS 

BURNER  PRESSURE 
INTERTURBINE  P  OR  T 
EXHAUST  PRESSURE 

MODULAR  PERFORMANCE 
TRENDING/EVENTS 

GEOMETRY 

THROTTLE 

FAULT  ISOLATION 

LIFE  CONSUMPTION 

AIRFRAME  ACCELEROMETER 
STRAIN  GAGE 

STRUCTURAL  LIFE  ASSESSMENT 

INCREASING 

CAPABILITY 
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(5)  The  on-board  processor  should  monitor  gross  engine  health 
continuously  and  evaluate  data  consistency.  Windows  for  automatic  performance 
data  collection  should  be  set  to  ensure  sufficient  data  to  perform  off-line 
trending  and  detailed  engine  performance  analysis. 

(6)  Data  transfer  hardware  must  be  portable  and  compact  for  operation  by 
flight  line  personnel.  The  equipment  should  automatically  download  data  from 
on-board  stw^age.  A  limited  processing  capability  should  permit  a  display  of 
data  at  the  flight  line  on  an  exception  basis.  The  transfer  unit  displays 
must  provide  the  diagnostic  data  to  support  go/no-go  decisions  required  by 
flight-line  (AGS)  maintenance  operation. 

(7)  The  off-board  temporary  data  storage  capability  should  accommodate 
aircraft  sortie  rates  and  wing  requirements.  The  data  transfer  equipment  must 
provide  the  capability  to  install,  trim,  and  calibrate  engines  and  support  all 
AGS  trim/troubleshooting  functions  without  reliance  on  other  AGE.  In 
addition,  this  unit  must  support  Installation,  calibration,  diagnosis,  and 
initialization  of  on-board  TEMS  hardware  in  a  stand-alone  mode. 

(8)  It  is  important  that  each  TEMS  program  development  includes  base 
level  (AGS)  procedures  for  maintaining  the  hardware  consistent  with  Air  Force 
practices  and  within  expected  operating  scenarios.  If  this  is  not  done, 
acceptance  of  the  TEMS  hardware  and  capability  by  the  AGS  may  be  compromised. 

C)  Deployment  capability  is  an  important  aspect  of  Air  Force 
operations.  This  scenario  places  special  requirements  on  the  TEMS  hardware. 
All  on-board  and  data  transfer  hardware  must  be  deployable  as  required  by 
installed  aircraft  mission.  This  requirement  dictates  the  design  of  highly 
reliable/low  maintenance  equipment  that  is  line-replaceable  whenever 
possible.  Moreover,  a  maintenance  specialist  should  not  be  required  for 
on-site  deployment  support  for  TEMS  equipment. 

(10)  Given  the  finite  storage  capability  of  the  data  transfer  hardware, 
the  Air  Force  must  evaluate  alternative  provisions  for  longer  term  storage  of 
performance  data  at  remote  for  lengthy  deployments. 
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4.4.2  Base  Computer 

The  base  computer  Is  a  repository  of  data  files  containing  maintenance 
Information.  These  data  systems  should  be  considered  as  Information  sources 
for  an  Integrated  engine  monitoring  capability.  The  functional  capabilities 
defined  by  the  task  force  require  data  from  existing  Information  sytems. 
Integration  of  the  following  base  level  data  subsystems  Is  recommended. 

(1)  MDC  data  should  be  used  to  reconstruct  major  installed  maintenance 
actions.  Coded  data  are  used  to  describe  the  maintenance  action  taken,  the 
nature  of  the  malfunction,  and  the  section  of  the  engine  where  the  work  was 
performed  (work  unit  code). 

(2)  Component  replacements  are  recorded  on  a  regular  basis  by  the  MMICS 
replacement  record  (TRE)  and/or  the  manual  781E  system.  It  Is  recommended 
that  these  be  correlated  against  data  entered  In  the  maintenance  data 
collection  (MDC)  system. 

(3)  Engine  TCTO  status  Is  tracked  by  MMICS  with  a  manual  backup  In  the 
engine  log.  Both  base  and  depot  users  require  consistent  lists  of  outstanding 
TCTOs  by  engine  serial  number.  The  list  must  be  updated  when  new  TCTOs  are 
issued,  or  when  outstanding  TCTOs  are  resolved.  Input  should  be  CRT-type 
entry  with  a  coordinated  base  level  interface. 

(4)  The  supply  system  Is  divorced  from  the  maintenance  data. system 
(MMICS,  MOCS).  The  task  force  Indicated  that  current  data  on  parts 
availability  should  be  accessible  at  engine  shop,  but  this  Is  viewed  as  a 
slgnlf  1c.;r.c  Interface  effort. 

4.4.3  Shop  Record  Information 

The  following  data  items  presently  located  at  the  JEIM  shop  are 
recommended  for  Integration  Into  the  automated  data  base. 

(1)  Major  uninstalled  maintenance  Is  summarized  In  the  significant 
history  forms  (AFT095)  filed  In  the  engine  log.  A  CRT  entry  of 
edited/abridged  data  from  the  log  report  (AFT095)  is  highly  recommended. 

(2)  Oil  analysis  data  are  currently  coded,  keypunched,  and  transferred 
to  the  San  Antonio  ALC  via  AUTODIN.  The  analysis  of  the  lab  data  at  the  base 
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leva!  is  usually  done  manually.  Integration  of  SOAP  data  by  mass  media  entry 
with  CRT  edits  from  the  SOAP  lab  is  recommended.  These  data  should  be  in  a 
format  consistent  with  both  base  and  depot  transfer  and  utilization. 

(3)  Borescope  status  reporting  could  be  Implemented  in  the  same  way  as 
AFT095  records.  It  is  recommended  that  a  borescope  summary  form  be  created 
and  recorded  at  base  via  CRT-type  entry.  The  precise  requirement  of  the 
interface  Is  dependent  on  the  final  definition  of  the  base  level  processing 
system,  but  should  be  automatic  after  initial  entry. 

‘.4.4  Depot/Central  Data  Items 

Data  received  through  the  depot  are  directed  toward  engine  configuration 
and  status  assessment.  Base  level  access  to  the  following  Items  is 
recommended. 

(1)  Engine  build  documentation  should  be  obtained  from,  and  provided  to, 
base  MMICS.  These  data  Include  the  serial  number,  part  numbers,  and  usage 
accumulation  to  date  for  each  tracked  component  of  a  module  or  engine. 
Initialization  of  the  data  base  requires  a  tape  entry  of  the  build 
configuration  for  each  tracked  engine.  Time/cycles  for  each  component  are 
Incremented  with  usage  data  from  the  TEMS. 

(2)  Engine/module  status  reporting  Is  provided  by  the  depot  D024 
system.  The  AF1534  forms  document  engine  removal  or  changes  in 
operational/repair  status.  A  CRT  entry  should  be  used  to  update  status 
summaries  at  the  base  level  and  provide  the  0024  record  Inputs  to  depot  via 
AUTODIN  as  standard  procedure. 

4.4.5  Summary  of  Data  Items  and  Interface  Recommendations 

The  data  items  and  interfaces  are  summarized  In  Table  4.10.  This  table 
forms  the  basis  for  the  requirements  on  the  hardware  and  software  system, 
detailed  in  the  following  sections. 
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Table  4.10 

Data  Item  and  Interface  For  Integrated  System 


DATA  ITEM 

SOURCE 

. 

SYSTEM 

AUTOMATIC 

INTERLINK 

ALTERNATIVE 

INTERFACE 

IHSTALLEO  PERFORMANCE/ 
LIFE  USAGE 

ENGINE  MONITORING 
SENSORS 

TEMS 

DCU/ODU 

FLOPPY  DISC 

ENGINE  BUILD 
DOCUMENTATION 

INITIALIZATION 

DECK 

MMICS 

MMICS 

TELELINK 

TAPE  ENTRY 

COMPONENT  REPLACEMENT 
RECORD 

AFTO  781E 

MMICS 

MM'CS 

TELELINK 

TAPE  ENTRY; 

CRT  ENTRY 

MAINTENANCE  DATA 
COLLECTION 

AFTO  349 

MMICS/ AFLC 

MMICS 

TELELINK 

TAPE  ENTRY; 

CRT  ENTRY 

SIGNIFICANT  HISTORY 

AFTO  95 

ENGINE  LOG 

N/A 

CRT  ENTRY 

TCTO  ACTIONS 

OUTSTANDING 

OD  829-1 

MMICS 

MMICS 

TELELINK 

TAPE  ENTRY 

ENGINE  STATUS 

AF  1534 

AF  1534 

N/A 

CARD  ENTRY 

PARTS  AVAILABILITY 

N/A 

SUPPLY  SYSTEM 

N/A 

CRT  ENTRY 

OIL  ANALYSIS  PROGRAM 

DO  2026 

OD  2027 

OAP  SYSTEM 
(SA-ALC) 

TBD 

CRT  ENTRY 

BORE SCOPE  STATUS 

INSPECTION  REPORT 

PROPOSED 

TBO 

CRT  ENTRY 

4.5  BASE  PROCESSOR  CONFIGURATION  OPTIONS 


Data  Items  and  Interfaces  have  been  Identified  to  support  Integrated 
monitoring.  The  processing  hardware  at  each  maintenance  echelon  must  be 
consistent  with  the  resulting  data  availability,  access,  and  transfer 
requirements.  The  data  system  to  support  Air  Force  engine  management  will  be 
distributed  between  base  and  central  (see  Figure  4.5)  facilities.  The  central 
storage  facilities  will  be  serviced  by  peripheral  processors  to  support  a 
variety  of  users.  There  are  several  viable  options  for  base  level 
Implementation  of  the  Integrated  engine  monitoring  capability. 

The  base  central  computer  will  be  linked  to  the  central  data  facility  via 
AUTOOIN  II.  This  computer  supports  all  engine  management  data  systems 
currently  In  place  (e.g.,  MMICS).  Automatically  acquired  data  and  the 
Integrated  monitoring  data  base  can  be  Implemented  In  the  following 
configurations:  (1)  within  the  base  computer  as  a  separate  set  of  software 
programs  and  operating  systems  or  (2)  in  a  distributed  computing  environment 
consisting  of  a  peripheral  front-end  processor  (shop  computers)  linked  to  the 
base  central  facility. 

The  first  configuration  Is  shown  in  Figure  4.6.  In  this  Implementation, 
TEMS  data  are  down-loaded  Into  the  data  collection  unit  at  the  flight  line. 
This  AGE  links  with  the  central  facility  to  transfer  raw  readings  to  the 
computer.  Processing,  prescreening  and  data  management  software  In  the 
central  computer  creates  the  necessary  data  base.  The  computer  also  must 
service  Interactive  user  access  as  in  the  current  system.  The  impact  of  the 
central  configuration  Is  summarized  as  follows: 

(1)  major  central  computer  software  development  must  be  Implemented; 

(2)  the  facility  must  be  sized  to  accommodate  high  surge  Inputs 
from  DOU  dumps  of  data; 

(3)  minimum  TEMS  AGE  Is  required  to  support  the  system  when  the 
unit  is  not  deployed; 

(4)  there  is  no  real-time  capability  beyond  snapshot  diagnostics 
during  deployment;  and 

(5)  data  transfer  during  deployment  could  be  a  significant  system 
design  driver. 
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Figure  4.6  Base  Central  Computer  Configuration  To  Support 
Automated  TEMS"Acquired  Data 
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The  distributed  configuration  Is  shown  In  Figure  4.7.  TEMS  data  are 
entered  and  supported  by  a  JEIM  shop  data  base  computer.  This  system  receives 
TEMS  data,  indexes,  prescreens,  and  updates  the  local  data  base.  User  Inquiry 
is  supported  In  the  shop  area.  The  shop  computer  Interfaces  with  the  central 
facility  during  direct  two-way  mass  transfer.  The  impacts  on  operations  are 
summarized  below. 

(1)  Minor  base  central  computer  software  development  is  required 
since  most  standard  data  systems  can  be  employed. 

(2)  Shop  computer  prescreens,  validates,  and  Indexes  TEMS  data  for 
reduced  information  transfer  loads  to  the  central  facility. 

(3)  The  shop  computer  is  dedicated  to  servicing  user  interaction  to 
provide  high  response  access  cpabillty. 

(4)  The  shop  computer  should  be  JEIM-deployable  to  support  all 
intermediate  functions  remotely.  This  would  provide  continuous 
history/trending/  diagnostic  capability  wherever  Intermediate 
maintenance  is  contemplated. 

The  complete  configuration  of  this  base  level  architecture  is  shown  In  Figure 
4.8  with  data  item  sources  and  system  Interfaces  identified. 

4.6  SOFTWARE  REQUIREMENTS 

Efficient  and  flexible  Implementation  of  an  Integrated  maintenance 
information  management  system  should  be  achieved  with  modular  and  upwardly 
compatible  software.  This  Is  crucial  in  light  of  the  long  life  cycle 
typically  required  in  Air  Force  management  systems.  Narrow  assumptions  of 
static  user  requirements  can  lead  to  a  "fixed  point"  software  design  that  is 
not  compatible  with  the  fact  that  diagnostics  and  maintenance  Information 
requirements  evolve  dynamically  over  the  life  of  the  engine.  Wear-In 
deterioration  of  new  engines  exhibit  Afferent  diagnostic  symptoms  and 
problems  than  those  encountered  by  engines  in  service  for  several  years. 
Specific  maintenance  procedures  and  support  policies  may  change  as  a  function 
of  cost  constraints. 

In  addition,  all  system  software  must  be  flexible  enough  to  handle  input 
from  a  range  of  monitoring  systems.  It  is  desireable  that  processing  and  data 
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management  logic  be  generic.  Acceptable  software  design  must  avoid 
customization  to  specific  application  equipment  when  possible. 

The  next  two  sections  discuss  an  approach  to  software  architecture  and 
application  programs  recommended  to  Implement  an  information  management  system 
to  support  performance  analysis  using  automated  TEMS  inputs. 

4.6.1  Architecture  of  the  Operating  System 

A  software  design  approach  that  facilitates  efficient  and  flexible 
Implementation  of  modular  and  upwardly  compatible  data  processing  is 
recommended.  The  distinctions  between  the  operating  executive  and  application 
logic  are  illustrated  in  Table  4.11. 

•  Processor  hardware  should  be  utilized  in  a  most  efficient  manner 
by  time-sharing  limited  resources  such  as  data  transfer  and 
memory. 

•  Software  development  should  use  a  fixed  operating  system 
established  early  in  the  development  cycle. 

•  Applications  software  should  be  developed  and  Implemented  with 
minimum  Interaction  and  Impact  on  other  system  functions. 

•  Modification,  revision,  transfer,  and  addition  of  software 
functions  should  be  performed  quickly  and  efficiently  without 
impact  to  system  operation,  documentation,  or  performance. 

•  Hardware  variances  should  be  accommodated  easily. 

Base  level  storage  contains  filed  entries  for  each  engine.  Information  in  the 
engine  file  should  include  parts  configuration,  aircraft  identification, 
operating  time  and  cycles  as  of  the  most  recent  recordings,  and  a  record  of 
data  entered  but  as  yet  unprocessed. 

4.6.2  Applications  Software 

The  software  architecture  to  support  a  maintenance  information  management 
system  must  be  synthesized  to  support  the  operational  scenarios  envisioned  for 
its  use.  This  includes  sequential  acquisition  and  qualification  of  data. 
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Table  4.11 


A  Comparison  Of  Operating  Executive  and  Application  Functions 


ISSUE 

OPERATING  EXECUTIVE 

APPLICATION  SOFTWARE 

PURPOSE 

OPERATE  PROCESSOR  AND 
ALLOCATE  RESOURCES 

1 

ACHIEVE  SPECIFIC 
FUNCTIONAL  OBJECTIVES 

COMMONALITY 

COMMON  TO  SEVERAL 
HARDWARE  ENVIRONMENTS 

SPECIFIC  TO  LOCATION 

AND  FUNCTION  ADDRESSED 

DEVELOPMENT 

VOLATILITY 

DEVELOPED  EARLY  IN 
PROGRAM 

MANY  MODIFICATIONS 

DURING  DEVELOPMENT 

AND  TEST 

RESOURCE 

UTILIZATION 

20  X 

80  % 

RELIABILITY 

HIGH-FIXED 

EARLY 

CONTINUALLY  IMPROVING 

USER  IMPACT 

LITTLE 

DIRECTLY  IMPACTS 

SYSTEM  OPERATION 

EFFECT  OF  MISSION 
CHANGE,  ENGINE 

MODE, MAINTENANCE 
PROCEDURES 

NONE 

LARGE 
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efficient  user  interface,  multi-indexed  query  capability,  and  multi-media  data 
transfer  and  output. 

The  operating  executive  coordinates  access  to  the  information  during 
application  routine  execution.  Two  types  of  application  software  must  exist. 
They  are  display  functions  and  data  processing  functions  (see  Figure  4.9  for 
typical  breakdown  of  modules). 

Display  functions  produce  data  products  on  the  CRT  (interactive)  or  in 
hard  copy  (off-line).  Usin>v  standardized  program  protocols,  application 
modules  should  be  developed  easily.  Data  processing  routines  implement  all 
automated  manipulation,  examination,  and  exception  of  the  data.  Routines  ia 
this  category  include  engine  performance  analysis,  trending,  alarms,  sensor 
diagnostics,  etc.  Development  time  on  this  software  will  be  greatly  dependent 
on  the  complexity  and  sophistication  of  the  routines  involved. 

The  software  must  be  executable  on  many  types  of  computational  units, 
e.g.,  the  base  computer  facility,  central  data  bank  computer,  peripheral 
display  processors,  etc.  This  Is  a  critical  element  in  the  design.  The 
application  functions  necessary  to  perform  data  input,  management,  and  output 
are  Illustrated  in  Table  4.12. 

4.7  MAINTENANCE  INFORMATION  MANAGEMENT  SYSTEM 

Software  has  been  developed  and  demonstrated  to  meet  the  requirements 
discussed  In  Sections  4.1  througn  4.6.  Some  of  the  data  products  of  the 
system  are  seen  in  Chapters  V  through  VII  In  the  discussion  of  the  analysis  of 
TEMS,  EDS,  and  IECMS  data.  For  a  more  comprehensive  look  at  the  system 
capabilities,  the  reader  is  referred  to  the  Maintenance  Information  Management 
System  user's  manual. 


124 


125 


Table  4.12 


Software  Functional  Description  Application  Modules 


SYSTEM  FUNCTION 

SOFTWARE  MODULES 

DATA  INPUT 

-  PERFORMANCE  DATA  ENTRY 

-  TIME/CYCLES/HOT  SECTION  UPDATES 

-  MAINTENANCE/REPAIR  ACTIVITY 

-  ENGINE  REMOVALS /MODULE  SWAPS 

-  INVENTORY  STATUS 

-  ENGINE  FILE  EDITING 

DATA  MANAGEMENT 

-  FILE  MAINTENANCE 

-  ACCESS  CONTROL 

-  ARCHIVING/ BACK  UP 

-  FILE  TRANSFER 

-  INTER-PROCESSOR  PROTOCOLS 

ENGINE  DATA 
ANALYSIS 

-  ENGINE  PERFORMANCE  ANALYSIS 

-  PER-ENGINE  DATE  MODULE 

-  TRENDING  ALGORITHM 

-  SENSOR  DIAGNOSTICS 

-  PERFORMANCE  SHIFT  CALCULATION 

-  VIBRATION  ANALYSIS 

-  OIL  ANALYSIS 

-  MAINTENANCE  HISTORY 

-  USAGE  TRACKING 

-  EXCEPTION  LOGIC 

OUTPUT 

-  INTERACTIVE  CONTROLS 

-  SUMMARY/ INDEX  DISPLAY 

-  DECISION  LEVEL  MODULES 

-  HARD  COPY  SUMMARIES 

-  MAGNETIC  TAPE  INTERFACE 

-  TERMINAL  DISPLAY  DRIVERS 

V.  APPLICATION  TO  A10/TF34  TEMS  FLIGHT  SERVICE 
EVALUATION  DATA 


5.1  INTRODUCTION 

Chapter  V  examines  the  concept  of  an  integrated  engine  monitoring  system 
within  the  framework  of  the  A10/TF34  flight  service  evaluation.  Test 
jackground  Is  provided  and  highlights  of  the  t  iSt  are  presented  which  define 
the  diagnostic  capabilities  of  the  TEMS.  Modeling  activities  are  followed  In 
the  development  of  the  thermodynamic  cycle  monitoring  algorithm.  Results  of 
the  algorithm  development  are  presented  Results  of  the  analysis  activities 
following  the  test  helped  to  elucidate  the  feasibilities  and  limitations  of 
automated  turbine  engine  monitoring,  as  an  Independent  element,  and  as  part  of 
an  Integrate!  set  of  mvlutenance  tools.  It  is  believed  that  the  vehicle 
driving  this  integration  is  the  thermodynamic  cycle  monitoring  algorithm. 

With  consideration  given  to  these  factors,  potential  Impacts  of  the  system  are 
discussed. 

5.2  TEST  BACKGROUND 

Before  discussing  the  details  of  the  test,  the  objectives  of  test  data 
evaluation  are  presented  as  follows: 

•  to  evaluate  data  accuracy,  repeatability  and  sensor  variations  In 
TEMS  data 

•  to  develop  algorithms  to  reduce  performance  data  to  usable 
parameters 

•  to  assess  applicability  of  test  results  to  the  engine  maintenance 
process 

The  flight  test  was  begun  In  November  1978  at  Myrtle  Beach  AFBSC  with 
five  aircraft.  A  sixth  aircraft,  modified  to  provide  structural  airframe  as 
well  as  engine  performance  data,  was  added  in  April  1979.  During  the  formal 
evaluation,  the  TEMS-equIpped  aircraft  had  acquired  1385  flights  and  2233 


flight  hours.  A  flight  service  evaluation  summary  is  presented  in  Table  5.1* 
which  compares  the  test  aircraft  to  a  control  grcuj  [43]. 

With  the  A10/TF34  TEMS  flight  test,  an  abundant  amount  of  diagnostic  and 
trending  data  became  available.  Data  included  in-flight  engine  data,  oil 
analysis  results  from  the  SOAP  system,  maintenance  hiscory  records  from  the 
maintenance  data  collection  system  (MDCS),  and  engine  configuration  data  from 
the  parts-tracking  element  of  the  maintenance  management  information  control 
system  (MMICS)  [44].  The  data  covered  a  12-month  period  of  test  performance 
(January  to  December  1979)  for  12  TEMS  engines.  The  data  provide  the  tool 
with  which  to  evaluate  an  automated  TEMS  and  Its  Integration  with  other 
maintenance  management  tools  employed  by  the  Air  Force.  A  description  and 
historical  background  of  the  TEMS  Is  now  presented. 

The  A10  TEMS  Is  designed  to  enhance  flight  line  diagnostics,  engine 
troubleshooting,  and  trim  procedures.  The  system  is  a  snapshot  recorder  which 
records  all  measured  signals  when 

•  an  engine  parameter  exceeds  a  threshold  value 

a  the  pilot  triggers  a  record  option 

•  certain  preprogrammed  flight  conditions  (e.g.  take-off,  cruise) 
are  met 

The  data  frames  consist  of  several  engine  variables,  engine  and  airframe 
serial  number  identification,  vibration  levels,  and  time/cycle  information. 

The  occurrence  of  an  event  is  indicated  on  an  engine  status  panel. 
Exceedance  limits  are  related  to  a  malfunction  code  that  can  be  examined  on  a 
flight  line  display  unit  with  all  the  measurements  taken  in  conjunction  with 
the  event.  Normal  operating  data  are  collected  without  display  and 
transferred  to  a  ground  station  for  storage  on  a  floppy  disc  and  later 
examination.  Figure  5.1  is  a  block  diagram  of  the  TEMS  configuration. 

The  TEMS  was  Initially  flight-tested  by  the  Air  Training  Command  (ATC)  on 
the  J-85  engine  of  the  T-38  aircraft  at  Randolph  Air  Force  Base.  The  results 
of  this  test  were  somewhat  disappointing.  The  system  flagged  slightly  less 
than  3  percent  of  the  engine  malfunctions  independent  of  a  pilot  squawk  or 
ground  crew  observation.  The  J-85  is  a  relatively  mature  engine  normally 
operated  in  a  benign  training  environment  and  maintained  by  experienced 
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Table  5.1 


Summary  of  A10/TF34  Test  Flight  Evaluation 


r - — - 1 - 1 

TEMS  AIRCRAFT 

CONTROL  A IRC 

FLIGHTS 

1,385 

1,127 

FLIGHT  HOURS 

2,233 

1,856 

ENGINE  REMOVALS 

4 

0 

GROUND  ABORTS 

13 

7 

AIR  ABORTS 

3 

0 

MMH/FH 

0.82 

0.35 

DOWN  TIME/FH 

0.33 

0.71 

NMCM  (HOURS) 

958 

1.247 

SUPPLY  DEMANDS 

TEMS  MHH/FH 

160 

0.021 

117 

AIRBORNE 
PROCESSING  UNIT 


Figure  S.l  TEMS  Hardware  Configuration 
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personnel.  The  number  of  problems  typically  experienced  by  the  engine  Is  not 
high.  It  was  reported,  however,  that  the  monitoring  system  did  provide 
valuable  Information  that  reinforced  a  cause-and-effect  Interpretation  of 
certain  engine  problems  [44]. 

After  the  ATC  evaluation,  the  TEMS  aircraft  were  transitioned  to  the 
Tactical  Air  Command  (TAC)  for  flight  evaluation  In  a  more  severe  operating 
environment  with  a  demanding  mission  profile.  Encouraging  results  In  this 
experiment  motivated  TAC  and  AFLC  to  transfer  hardware  for  further  systems 
evaluation  on  six  A10  aircraft. 

The  distribution  of  TEMS-detected  events  during  the  12-mont.h  A10  flight 
service  evaluation  Is  presented  In  Figure  5.2.  The  large  number  of  oil 
pressure  fluxes  was  the  result  of  software  problems.  Problems  with  wiring 
Installation  and  loose  vibration  sensors  affected  the  Incidence  of  vibration 
events.  The  high  level  of  VG  events  was  attributed  to  a  discontinuity  In  the 
schedule  curve  that  was  progammed  Into  the  TEMS.  These  system  problems 
resulted  In  a  high  false  alarm  rate  during  the  early  portion  of  the 
evaluation.  After  the  appropriate  fixes  were  Implemented,  the  TEMS  stabilized 
to  a  much  lower  alarm  rate  and  the  quality  of  the  data  Improved  dramatically. 

Table  5.2  summarizes  the  effectiveness  of  the  TEMS  using  the  categorical 
criteria  of  the  test  plan.  The  criteria  are  as  follows: 

Good:  TEMS  Indicates  no  discrepancy  has  occurred.  * 

Type  1:  Pilot  and  support  personnel  report  discrepancy 
along  with  TEMS. 

Type  2:  Pilot  and  support  personnel  report  discrepancy  for 
which  the  TEMS  Is  programmed  to  detect;  however, 
the  TEMS  Indicates  no  problem. 

Hit:  An  engine  discrepancy  occurs  and  Is  correctly  Identified  by 

the  TEMS. 

Type  1:  TEMS  alone  identifies  fault  which  requires  a 
maintenance  action. 

Type  2:  Both  TEMS  and  support  personnel  or  pilot  detect 
discrepancy  which  requires  a  maintenance  action. 


NUMBER  OF  DETECTED  EVENTS 


1  NOV  78  -  31  OCT  79 
SOURCE:  ASD  MALTRAN  PROGRAM 
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Table  5.2 

Categorical  Analysis  Per  Test  Plan  1  November  Through 

31  October  1979  144] 


NUMBER  OF 
FLIGHTS 


PILOT 

FLIGH 

HOURS 


1,289  2,014  2,233  597  3 


HITS 

1 

2  3 

4 

5 

10  249 

2 

ACCURACY  TOTAL 

ACCURACY  PERCENTAGES 

GOOD 

1,208 

93.716 

HIT 

15 

1.241 

FALSE  ALARM 

65 

5.042 

Type  3: 


TEM5  alone  Identifies  a  discrepancy  (usually  a 
limit  exceedance),  but  the  severity  and  duration  of 
the  problem  does  not  require  immediate  maintenance. 


Type  4:  Engine  problem  identified  by  analysis  of  TEMS  data 
(a  malfunction  record,  or  pilot  report  does  not 
Indicate  a  problem). 

Miss:  A  discrepancy  occurs  which  the  TEMS  Is  programmed  to  detect; 
however,  no  discrepancy  is  recorded. 

False  Alarm:  TEMS  Indicates  an  engine  malfunction  when  none 
has  actually  occurred. 

Out  of  Scope:  An  engine  discrepancy  occurs,  but  is  not 
programmed  in  the  TEMS  for  detection. 

Results  indicate  that  this  version  of  the  TEMS  had  matured  over  Its 
predecessor  on  the  J-85  engine.  The  test  was  conducted  on  a  non-interference 
basis.  Consequently,  emphasis  was  placed  on  diagnostics,  and  full  TEMS 
utilization  for  directing  maintenance  was  compromised. 

5.3  THERMODYNAMIC  CYCLE  MONITORING  ALGORITHM  DEVELOPMENT 

The  following  section  of  Chapter  V  discusses  the  way  in  which  the  theory 
presented  in  Chapters  II  and  III  has  been  applied  to  the  A10/TF34  TEMS  flight 
service  evaluation  data.  The  objective  of  this  effort  is  to  develop 
algorithms  whlcij  reduce  TEMS  data  to  usable  performance  parameters. 
Ultimately,  the  goal  is  the  prediction  of  engine  failure  by  means  of  a  fault 
estimation  algorithm.  To  simplify  the  discussion  of  results  obtained  during 
algorithm  development.  It  will  be  treated  as  a  three-step  process: 

(1)  Data  screening,  including  windowing  and  sensor  fault  detection. 
Isolation,  and  accommodation. 

(2)  Development  of  models  for  use  in  estimating  engine  performance 
parameters. 

(3)  Reduction  of  performance  parameters  to  module-  directed  health 
ratings. 

Each  step  of  the  development  will  be  followed,  observations  will  be 
Illustrated,  and  results  will  be  presented. 


5.3.1  Data  Screenln 


Production  of  accurate  performance  monitoring  results  depends  on  the 
quality  of  data  used  In  the  algorithmic  models.  Prior  to  developing  a  QLR 
model  for  the  TF34/A10  TEMS  data*  the  data  were  analyzed  to  determine 
appropriate  usage  profiles  and  levels  of  sensor  noise.  Downstream  In  the 
algorithm  development  process*  appropriate  fault  parameters  were  chosen. 

The  first  stage  of  the  screening  process  occurs  on-board  the  A10  with  the 
TEMS  recording  logic.  Data  are  recorded  when  one  of  six  window  conditions  Is 
satisfied  by  the  aircraft  and  engine.  These  window  conditions  are  shown  In 
Table  5.3.  For  the  performance  analysis*  data  were  chosen  from  the  trim* 
cruise  performance*  and  take-off  windows.  For  12  installed  engines  over  the 
12-month  period  (for  which  data  were  available)*  over  7000  data  scans  were 
produced. 

Not  all  of  these  data  represent  the  normal  operating  conditions  because 
of  sensor  failures,  sample  outliers,  equipment  malfunction*  and  off-nominal 
window  conditions.  The  data  were  screened  to  eliminate  all  scans  with  hard 
sensor  failures.  Nonrepresentative  points  were  also  screened  to  obtain  a  more 
uniform  data  sample.  Little  Information  Is  lost  In  this  process  when  a  large 
population  Is  used.  There  were.6100  valid  points  after  this  screening 
process.  Figure  5.3  shows  a  sample  scatter  plot  of  stabilized  TEMS  data 
before  screening.  The  screened  data  are  shown  In  Figure  5.4.  Table  5.4  shows 
the  final  screening  criteria  used  In  the  data  selection  process.  Sample  data 
scatter  plots  are  shown  In  Figure  5.4.  The  data  uniformity  Is  significantly 
enhanced  in  all  channels  except  VG.  The  VG  data  contain  significant 
outliers.  Since  this  variable  Is  not  used  In  the  model  development*  no 
attempt  was  made  to  screen  this  channel. 

5.3.2  Model  Development 

As  explained  In  Chapters  II  and  III*  the  procedure  for  estimating  engine 
fault  parameters  requires  a  baseline  model  and  a  fault  parameter  (or 
performance)  model.  The  engine  baseline  model  was  generated  using  processed 


Table  5.3 


A10  TEMS  Data  Acquisition  Windows 


TYPE 

DESCRIPTION 

CONDITIONS 

1 

TAKE-OFF 

-  ENGINE  ON 

-  NG  >  56* 

-  IN-AIR  SIGNAL  TRANSITION 

-  KCAS  >  100  KNOTS 

2 

CRUISE 

-  NG  COR  >  85.4* 

-  [PLA  RATE |  <  l°/2  SEC  FOR  >  16  SEC 

-  { T2C  RATE |  <  l°/2  SEC  FOR  >  16  SEC 

-  NO  GUN  FIRE 

-  200  <  KCAS  <  300  KNOTS 

-  2500  <  ALT  <  20,000  FT 

-  a  <  15° 

3 

TRIM 

-  NG  COR  >  85.4* 

-  | PLA  RATE |  <  l°/2  SEC  FOR  >  60  SEC 

-  | T2C  RATE I  <  l°/2  SEC  FOR  >  60  SEC 

-  NO  GUN  FOR  >  60  SEC 

-  (KCAS  RATE |  <  30  KN/MIN  FOR  >  60  SEC 

-  ALT  <  10,000  FT 

-  a  <  15° 

-  PLA  >  50° 

Figure  5.3  Raw  TEMS  Stabilized  Scans 


Figure  5.4  TF34/TEMS  Screened  Data  Scans 


CRITERIA 


WINDOW  -  1,  2,  OR  3 
90*  >  NF  >  71.5* 

97.1*  >  N6  >  86.6* 

100°  >  T2C  >  0° 

3300  ??H  >  WF  >  1237  PPH 
70.6  PSIA  >  PT5  >  0  PSIA 
342  PSIA  >  PS3  >  116  PSIA 
831°C  >  in  >  610°C 
40°C  >  OAT  >  -34.2°C 
PS3  <  4.86  PT5  -  72.6  PSIA 
PS3  >  4.53  PT5  +  29.6  PSIA 
PS3  >  0.0777  WF  +  61.5 
PS3  <  0.0777  WF  -  0.5 
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TEMS  data,  while  the  fault  parameter  model  was  extracted  from  engine  status 
dec!<  data. 

Baseline  models  were  derived  from  the  filtered  TEMS  data  base  for  11 
variables.  Residual  analyses  were  performed  on  each  of  the  models.  Results 
of  the  analyses  are  listed  in  Table  5.5.  Standard  deviations  for  the  models 
are  shown  in  comparison  with  the  accuracy  specified  for  the  sensor  hardware. 

It  can  be  seen  that  the  channel  fit  error  is  significantly  greater  than  the 
error  which  is  latent  in  the  sensor  hardware  design.  The  differences  are 
explained  by  uncorrelated  residuals  which  can  be  attributed  to: 

•  engine-to-engine  variations 

•  window  effects 

•  stabilization 

•  sensor  errors 

•  deterioration 

•  nonstationary  processes 

•  other  non-observable  phenomena 

An  illustration  of  the  residual  analysis  results  is  shown  in  Figure  5.5. 
The  random  distribution  of  the  residuals  about  zero  is  an  indication  of  the 
correctness  of  the  model.  Figure  5.5  shows  a  sample  plot  of  PS3  residual 
versus  total  engine  operating  time  for  one  engine.  A  dashed  line  on  the  plot 
indicates  a  gradual  decline  in  the  PS3  residual  with  time.  This  trend  may 
reflect  a  long-term  engine  degradation. 

In  addition  to  providing  a  visual  tool  for  the  evaluation  of  regression 
models,  residual  plots  depict  outliers.  Figure  5.6  shows  the  effects  of  soft 
PS3  and  PT5  sensor  failures.  The  NF  vs.  PLA  plot  in  Figure  5.7  shows  three 
PLA  failures.  From  this  plot  it  is  not  clear  whether  the  PLA  or  NF  sensor  has 
failed.  The  sensor  algorithm  described  in  Chapter  III  not  only  detects 
failures  but  isolates  them;  in  this  example,  the  PLA  failure  was  isolated. 

Soft  ITT  sensor  failures  are  seen  in  Figure  5.8.  The  ITT  sensor  failure  has 
been  confirmed  by  MOC  data.  The  failed  channels  are  reconstructed  before  the 
data  are  passed  to  the  estimation  algorithm.  This  prevents  the  effects  of 
sensor  failures  being  interpreted  as  engine  or  module  failures.  These  very 
promising  results  indicate  the  power  of  the  sensor  diagnostic  algorithm  and 
its  usefulness  in  the  processing  of  engine  data. 
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Table  5.5 

Baseline  Model  Accuracy 


SENSOR 

CHANNEL  FIT  ERROR  1 

HARDWARE  SPECriCATION 

PS3  (PSIA) 

2.8 

1.8 

PT5  (PSIA) 

1.3 

0.4 

in  <°c> 

10.6  . 

3.0 

NG  {%  RPM) 

.41 

0.1 

WF  (PPH) 

76. 

50. 

NF  (X  RPM) 

.42 

0.1 

T2C  (°C) 

2.6 

1.0 

PTO  (PSIA) 

.29 

.12 

DPAMB  (PSIA) 

.34 

0.6 

Figure  5.5  Residual  Plot  For  PS3  Model-All  Engines 
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Figure  5.8  (Continued) 


The  fan  speed  residual  for  a  single  engine  Is  shown  In  Figure  5.8.  The 
residual  plot  shows  short-term  engine  deterioration  and  a  residual  HF  jump 
which  Is  correlated  with  a  maintenance  action.  The  residual  levels  are  used 
by  the  estlmatlon/flltering  algorithm  to  produce  module  health  Indices.  The 
health  Indices  are  quantitatively  significant.  Include  uncertainty  levels  In 
the  estimates,  and  are  directed  to  an  engine  component  or  module.  While  the 
residual  levels  are  related  to  the  module  health  Indices,  the  latter  are 
operationally  significant  quantities. 

Using  a  procedure  similar  tc  that  used  In  developing  baseline  models, 
fault  models  were  also  generated.  These  models,  however,  were  extracted  from 
TF34  status  deck  data.  The  data  base  used  for  this  program  was  created  by 
executing  the  status  deck  over  a  range  of  flight  conditions.  For  each  set  of 
flight  conditions,  the  program  was  executed  while  varying  engine  component 
efficiencies  and  flow  areas  (l.e.,  fault  parameters). 

Five  variables  (PS3,  PT5,  ITT,  NG,  and  Itf)  describing  engine  operation 
were  modeled  in  terms  of  11  fault  parameters.  Definitions  of  these  fault 
parameters  are  given  In  Table  5.6.  By  analyzing  the  residuals  of  these  models, 
strong  correlations  between  dependent  and  Independent  variables  were 
Identified.  Results  of  the  analyses  are  shown  In  Table  5.7.  For  example,  PT5 
Is  strongly  correlated  with  anFAN,  aAFAN,  Ahhc,  aAhc,  AnLT,  aAlt, 
and  aAq. 

5.3.3  Lumped  Parameters  -  Module  Indices 

As  explained  in  Chapter  III,  to  establish  reasonable  error  levels,  a 
limited  set  of  fault  parameters  should  be  estimated.  By  examining  the 
dispersion  matrices  for  cases  when  from  one  to  six  parameters  are  estimated, 

;t  was  decided  to  lump  the  fault  parameters  into  three  parameters  (see  Table 
5.8).  Three  module-directed  rating  parameters  result,  which  are  linear 
combinations  of  the  original  11  fault  parameters.  These  ratings  are  then 
averaged  to  obtain  the  net  rating  ^or  the  overall  engine. 


Table  5.6 


Fault  Parameter  Definitions 


AnFAN 

aafan 

AnHC 

aahc 

awBld 

Ar>  BURN 
(APr)BURN 
AnHT 

aAht 

a\t 

AAlT 

aa8 


FAN  EFFICIENCY  DELTA 

FAN  AREA  DELTA 

CORE  EFFICIENCY  DELTA 

CORE  AREA  DELTA 

BLEED  FLOW  DELTA 

BURNER  EFFICIENCY  DELTA 

BURNER  PRESSURE  RATIO  DELTA 

HIGH-PASS  TURBINE  EFFICIENCY  DELTA 

HIGH-PASS  TURBINE  AREA  DELTA 

LOW-PASS  TURBINE  EFFICIENCY  DELTA 

LOW-PASS  TURBINE  AREA  DELTA 

AUGMENTOR  AREA  DELTA 
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Table  5.8 

TF34/TEMS  Id^ntif lability 


ASSUMPTION: 

-  NOISE  LEVELS  FROM  DATA  ANALYSIS 

-  FIVE  PERFORMANCE  EQUATIONS 

-  DISTRIBUTION  OF  FLIGHT  POINTS 

-  SINGLE-POINT  ESTIMATOR 


DISPERSION 

NUMBER  OF  PARAMETERS 

MINIMUM  ERROR 

1 

0.2% 

2 

0.4% 

3 

1.6% 

4 

2.2% 

5 

4.5% 

6 

LARGE 

THREE-PARAMETER 
SET  SELECTED 


5.4  HIGHLIGHTS  OF  RESULTS 


The  processing  of  TEMS  data  by  the  TCM  algorithm  culminates  with 
estimates  of  three  module-directed  rating  parameters;  a  low  spool  rating 
parameter  (LOSR),  a  high  pressure  turbine  parameter  (HPTR),  and  a  core 
parameter  (CORK).  Also  computed  is  a  net  engine  rating  ( NETR )  which  is  the 
numerical  average  of  the  three  module  parameters.  ..lustrations  of  the 
results  of  the  TCM  algorithm  are  now  presented. 

Figure  5.9  shows  examples  of  the  NETR,  CORR,  HPTR  and  LOSR  rating 
parameters  as  a  function  of  total  engine  operating  time  (TOT)  for  engine 
5226.  Steady  engine  deterioration  between  600  and  760  operating  hours  is 
reflected  by  a  decreasing  net  engine  rating.  A  water  wash  of  engine  5226  at 
TOT  -  760  hours  results  in  an  Improvement  in  the  net  engine  rating.  A  period 
of  slow  engine  degradation  then  follows. 

Closer  examination  of  the  module  parameters  in  Figure  5.9  shows  that  the 
maintenance  action  at  760  hours  results  primarily  in  an  improved  core  rating. 
Apparently,  heavy  gun  gas  ingestion  has  a  significantly  greater  effect  on  the 
low-spool  module.  Similar  results  occur  for  the  5237  engine  as  shown  in 
Figure  5.10. 

These  plots  confirm  that  the  TCM  algorithm  can  reduce  engine  monitoring 
data  to  operationally  significant  module  health  indices.  They  also  provide 
graphic  evidence  o*  rhe  trending  capabilities  of  this  analysis  tool,  and 
suggest  its  application  for  the  purpose  of  predicting  or  scheduling 
maintenance  actions.  Conceivably,  the  lines  drawn  to  fit  trend  plots  could  be 
extrapolated  to  predetermined  rating  levels,  at  which  time  a  maintenance 
action  should  bo  scheduled. 

Figure  5.11  provides  an  examination  of  short-term  versus  long-term 
trends.  For  example,  the  short-term  Improvement  in  the  net  rating  of  engine 
5237  at  400  operting  hours  corresponds  to  an  engine  water  wash.  However,  the 
single  trend  Vine  (which  suppresses  short-term  improvements)  shows  the  long 
run  effects  of  gradual  engine  wear.  Additional  plots  indicate  that  this 
short-  and  long-term  trend  phenomena  is  observable  in  many  engines 
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Figure  5.9  (Continued) 
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Health  Indices  for  E5237 
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Figure  5.11  Short-  vs.  Long-Term  Trends 
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Figure  5.11  (Continued) 
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Figure  5.11  (Continued) 
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Correlations  between  significant  maintenance  actions  and  Improvements  in 
the  net  engine  rating  are  shown  in  Figure  5.12.  One  engine,  5240,  has  no 
significant  maintenance  actions  and  a  plot  of  NETR  shows  only  a  slow,  gradual 

decline. 
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VI.  APPLICATION  F*  F15/F100  EDS  FLIGHT  TEST  DATA 


b.l  INTRODUCTION 

Ch^ter  VI  presents  a  discussion  of  the  activities  at  SCT  in  the 
application  of  tf  dynamic  cycle  monitoring  to  F15/F100  EDS  flight  test 
data.  Test  background  is  provided  and  a  discussion  of  analysis  techniques  and 
n  suits  Is  pursued.  As  explained  earlier  chapters,  the  success  of  a 
thermodynamic  cycle  monitoring  i1*„.‘1t.hm  is  dependent  on  the  quantity  and 
quality  of  the  data  wF  .>  are  processed.  With  early  phases  of  the  flight 
test,  insufficient  amounts  of  data  were  available.  Consequently,  activities 
at  SC’’  were  directed  towards  improving  the  data  acquisition  logic  of  the  EDS 
and  analyzing  „he  existing  data  to  improve  its  repeatibility.  Therefore, 
discuss, Ion  of  analysis  activities  will  proceed  as  follows: 

•  initial  model  development  activities  and  data  analysis 

•  high-power/ low-power  analyses 

•  cluster  analyses 

•  pilot  option/automatic  ta!‘e.-off  record  analyses 

a  conclusive  model  development  and  red»;tion  of  parameters  to 
module-directed  indices 

6.2  TEST  BACKGROUND 

The  EDS  flight  evaluation  was  conducted  at  Langley  AFB,  Virginia,  from 
April  19PJ  through  June  1981.  This  evaluation  was  conducted  in  three  phases: 
the  debug  nhase,  tne  flight  evaluation  phase,  and  the  extended  flight  j 

evaluation  phase  (see  Table  6.1).  Five  F15  aircraft  and  eleven  F100  engines 
from  the  1ST  Tactical  Fighter  Wing,  were  equipped  with  the  EDS.  During  the 
evaluation,  nearly  '100  sorties,  encompassing  almost  1400  aircraft  flight 
hours  (AFH)  and  2700  engine  flight  hours  (EFH)  were  generated  with  the  EDS 
aircraft/  ngines.  Over  41C0  engine  operating  hours  (EOH)  were  accrued  on  the 
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Table  6.1 


EDS  Flight  Evaluation  Phase  [45] 


PHASE 


FROM 


DEBUG 

FLIGHT  EVALUATION 


1  APRIL  1980 
1  SEPT  1980 


DATES 

TO 

31  AUG  1980 
12  DEC  1980 


EXTENDED  FLIGHT  EVALUATION 


13  DEC  1980 


28  JUNE  1981 


eleven  EOS  engines.  Summaries  of  the  aircraft  and  engine  flight  statistics 
are  provided  in  Tables  6.2  and  6.3  [45]. 

The  objectives  of  the  test  were  to  evaluate  [46]: 

•  automatic  time/cycle  data  recording  and  transfer  to  MMICS 

•  validity  of  fault  detection  and  Isolation  of  EOS 

•  ability  of  AF  personnel  to  maintain  EDS 

•  the  ability  of  EOS  to  acquire  in-flight  data  automatically  for 
use  in  engine  trending  and  engine  performance/trim  status 

•  the  supportability  of  EDS 

•  life  cycle  cost  parameters  including  secondary  damage  reduction 
resulting  from  early  detection  of  requirements  for  maintenance 
actions 

•  the  ability  of  EDS  to  meet  the  31  TAC/AFLC  requirements 

•  EDS  ground  equipment  units  as  aircraft  flight  support  equipment 

A  brief  description  of  the  EDS  is  now  provided  with  a  summary  of  the  amount 
and  type  of  data  which  were  collected,  and  some  specific  observations  of  the 
test  experience. 

The  EDS  system  uses  a  series  of  engine  transducers  mounted  in 
conveniently  located  positions  in  the  gas  path.  The  engine,  as  well  as 
lubrication  and  fuel  distribution  systems,  is  monitored  to  detect  out-of-limit 
behavior.  Subsystem  variables  are  sampled  continuously  by  an  engine-mounted, 
fuel-cooled  microprocessor  system,  the  engine  multiplex  (EMUX).  This 
processor  Is  connected  via  a  data  bus  to  an  airframe-mounted  avionics  computer 
dedicated  to  the  EDS,  the  data  processing  unit  (DPU).  The  DPU  stores  data 
consisting  of  time  histories  of  key  engine  variables  before,  during,,  and  after 
an  event  Is  detected.  These  data  are  later  recoverable  for  general  analysis 
to  isolate  faulty  behavior. 

In  addition  to  fault  information,  steady-state  data  are  acquired  in 
flight  for  performance  and  trend  checks.  These  data  "points'*  are  recorded 
when  aircraft  and  throttle  states  have  not  changed  significantly  for  a 
predetermined  settling  period. 
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Table  6.2 


EDS  Aircraft  Flight  Statistics  [45] 


AIRCRAFT 
TAIL  NO. 

DEBUG 

S0RTIES/AFH 

FLIGHT 

EVALUATION 

EXT.  FLT. 
EVALUATION 

TOTAL 

74-099 

30/34.6 

68/92.2 

121/150.4 

219/277.2 

74-103 

115/136.9 

39/51.7 

1/1.1* 

155/189.7 

74-105 

71/88.9 

43/58.6 

102/127.7 

216/275.2 

74-107 

118/147.7 

73/103.8 

94/111.5 

285/363.0 

74-108 

38/47.6 

76/92.8 

103/125.3 

217/265.7 

372/455.7 

299/399.1 

421/516.0 

1092/1370.8 

*  Sent  to  Warner  Robbins  AFB  for  Major  Airframe  Repair  In 
December  1980. 
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Table  6.3 


EDS  Engine  Flight  Statistics  [45] 


ENGINE 

S/N 

DEBUG 

SORTIES/EFH/EOH 

FLIGHT 

EVALUATION 

EXT.  FLT. 
EVALUATION 

TOTAL 

EDS 

TOT* 

680160 

52/62.4/104.0 

36/54.9/70.1 

118/140.0/217 

206/257.3/391.1 

1664.7 

680311 

49/57.7/95.0 

63/77.3/125.4 

38/51.9/76.4 

150/186.9/296.8 

1575.8 

680330 

62/73.1/107.0 

77/99.1/142.5 

93/112.8/169.7 

232/285.0/419.2 

1369.6 

0804 IS 

23/29.9/57.4 

74/95.0/142.2 

104/127.7/200.8 

201.252.6/400.4 

974.3 

680470 

122/152.2/254.4 

40/51.9/85.4 

97/120.1  '176.4 

259/324,2/516.2 

863.6 

680528 

61/73.4/115.6 

38/47.2/78.3 

96/118.7/177.6 

195/239.3/371.5 

1154.4 

680639 

70/87.9/152.8 

45/59.9/84.6 

42/50.9/78.6 

157/198.7/316.0 

769.7 

680694 

115/136.9/211.4 

39/50.9/82.3 

39/47.5/75.0 

193/235. 3/36U.i' 

1271.3 

680722 

58/72.5/112.2 

63/84.5/126.0 

0,0.013.0 

121/157.0/241.2 

906.0 

680801 

117/146.4/224.6 

13/18.4/29.6 

94/114.7/172.0 

224/279.5/426.2 

1252.4 

680907 

13/15.1/37.4 

66/94.2/138.4 

122/149.9/212.2 

201/259.2/368.5 

1065.8 

742/907.5/1471.8 

554/733.3/1105.3 

843/1034.2/1558.7 

2139/2675.0/4135.8 

*Tot«l  Operating  Time  (Hours)  as  of  28  June  1981 
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Data  acquired  by  the  DPU  for  performance  and  trend  consist  of  several 
samples  which  are  processed  to  remove  noise  and  are  stored.  After  a  flight, 
the  data  generated  in  flight  are  passed  to  one  of  two  portable  units,  the  data 
collection  unit  (DCU),  or  the  data  display  unit  (DOU)  for  remote  processing. 
The  DOU  is  used  for  engine  troubleshooting  and  trim.  It  is  connected  when 
trouble  flags  apper  in  the  DPU  panel.  The  DCU  i-  used  under  normal  conditions 
to  retrieve  stored  data  for  trending  and  analysis.  These  data  are  made 
available  to  a  flight  test  dedicated  ground  station  computer  for  on-site 
processing  or  off-base  transfer  to  a  central  facility.  A  schematic  of  the 
data  collection  process  is  shown  in  Figure  6.1. 

The  data  acquisition  windows  for  the  EDS  are  as  follows: 

•  performance* 

•  trend/stable* 

•  trim/ground  run 

•  pilot  option 

•  diagnostic  events 

•  recording  is  inhibited  in  the  case  of  an  exceedance 

Based  on  the  data  collected  between  1/3  and  1/12/80,  EDS 
system  reliability  is  summarized  below  [47]: 

HITS  GOODS  FALSE  II  FALSE  I  MISSES  ACCURACY 
TOTAL:  63  1006  630  99.7 

(The  reliability  criteria  used  here  are  the  same  as  those  applied  in  the 
evaluation  of  the  A10/TF34  TEMS. ) 

During  the  course  of  the  flight  evaluation,  several  problems  were 
experienced  In  the  acquisition  of  the  data  records.  Problems  involved  the 
rate  and  power  setting  at  which  the  data  were  acquired.  As  the  Flight  Test 
Program  progressed,  new  data  sets  were  sent  to  SCT  for  analysis.  The  initial 
data  set  transmitted  contained  an  insufficient  amount  of  trending  data. 

During  the  first  nine  months  of  the  program,  a  trending  data  acquisition  rate 
of  10  per  100  EOH  was  experienced,  while  in  the  next  three  months,  a  rate  of  2 
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per  100  EOH  was  experienced.  These  rates  are  small  when  compared  to  the 
A10/TF34  TEMS  rate  of  35  per  100  EOH.  Late  in  the  evaluation,  several  changes 
were  made  to  the  EOS  software  and  an  additional,  quasi-stabilized  (i.e., 
take-off)  trending  record  was  added.  After  these  changes  were  made, 
acceptable  data  acquisition,  from  both  a  rate  and  power  setting  standpont,  was 
realized. 

A  summary  of  the  data  record  transmittals  from  Langley  AFB  in  St.  Louis 
to  the  CYBER  175  computer  at  the  WPAF8  is  given  in  Table  6.4.  In  addition  to 
the  usage,  trend,  performance  check,  and  take-off  records,  an  automated  EDS 
maintenance  record  file  was  to  have  been  transmitted.  Because  of  changes  in 
the  contractual  responsibilities  of  maintenance  personnel  during  the  course  of 
the  program,  maintenance  records  were  sent  with  only  20  percent  of  the 
transmittals. 

6.3  MODEL  DEVELOPMENTS 

The  initial  baseline  models  which  were  developed  reflect  the  paucity  of 
EDS  data  in  the  early  part  of  the  program.  Using  the  methods  which  were 
applied  to  TEMS  data,  but  without  tightly  windowing  the  data,  baseline  models 
were  created.  Tables  6.5  and  6.6  present  initial  model  development  results. 
The  large  baseline  model  standard  deviations  can  be  attributed  to  two 
factors:  the  scarcity  of  data  and  the  flight  conditions  for  which  the  data 
were  collected.  Large  differences  between  flight  data  model  statistics  and 
deck  model  statistics  are  attributable  to  many  factors,  the  most  outstanding 
being  that  the  portions  of  the  flight  envelope  from  which  EDS  data  were 
gathered  were  inconsistent  with  status  deck  flight  conditions.  This  is 
illustrated  in  Table  6.5. 

With  the  second  and  third  data  set  transmittals,  new  versions  of  the 
baseline  models  were  developed.  Data  were  screened  using  the  previously 
developed  models.  It  can  be  seen  in  Table  6,7  that  with  each  successive 
model,  the  standard  deviations  showed  improvement.  Model  errors  were  not  only 
attributable  to  data  scarcity,  but  to  the  fur.t  that  the  data  are  not  uniformly 
scattered,  and  that  with  early  data  transmittals,  data  are  clustered  mainly  in 
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Table  6.4 


Record  Transmittal  Summary  By  Engine  Serial  Number  [45]  \ 


ENGINE 

— 

USAGE 

TREND 

PERF.  CHK. 

TAKEOFF 

1 

S/N 

RECORDS 

RECORDS 

RECORDS 

RECORDS 

] 

P60160 

46 

22 

9 

18 

P680311 

29 

24 

11 

7 

P 6803 30 

65 

37 

31 

17 

: 

P680415 

50 

35 

24 

24 

I 

P680470 

44 

34 

30 

36 

i 

P680528 

34 

25 

17 

19 

i 

j 

P680639 

26 

25 

7 

0 

i 

P680694 

44 

42 

24 

11 

y 

P680722 

31 

18 

12 

0 

•] 

i 

P630801 

40 

26 

26 

24 

■j 

j 

P680907 

55 

33 

1£ 

37 

464 

321 

207 

193 

j 

, 

TOTAL  RECORDS 

-  1185 

1 75 


J/.1)  All f«£  A.U.n'iii 


Table  6 . 5 


Variable  Means 


UNITS 

VARIABLE 

STATUS  DECK 

DATA  (636  POINTS) 

EDS  FLIGHT 

DATA  (45  POINTS) 

RPM 

N1 

8714 

7406 

RPM 

N2 

11,650 

10,770 

PS1 

PT25C 

29.13 

24.68 

°C 

TT2 

7.428 

25.09 

PPH 

WFPC 

5203 

3097 

PSI 

PB 

208.3 

146.4 

°C 

T25C 

99.35 

87.02 

PSI 

PT6 

26.47 

21.78 

°C 

TS3 

311.7 

340.0 

°C 

FTIT 

702.2 

606.6 

176 


Table  6.6 


Model  Standard  Deviations 


UNITS 

VARIABLE 

STATUS  DECK 

DATA  (636  POINTS) 

EDS  FLIGHT 

DATA  (45  POINTS) 

RPM 

N1 

92 

180 

RPM 

N2 

40 

250 

PSC 

PT25C 

.13 

.83 

°C 

TT2 

1.7 

4.2 

PPH 

WFPC 

220 

180 

PSI 

PB 

1.3 

6.3 

°C 

T25C 

.97 

4.8 

PSI 

PT6 

.79 

1.2 

°C 

TS3 

1.5 

11.9 

°C 

FTIT 

3.3 

18.0 

Table  6.7 

F100  Model  Standard  Deviations 


_ RASFLTNE  MODEL 

STATUS 

DECK 

MODEL 

VARIABLE 

UNITS 

SEPT  '80 
MODEL 

NOV  '80 
MODEL 

DAN  '81 
MODEL 

T25C 

°C 

4.8 

2.6 

2.4 

.97 

PT25C 

PSI 

0.83 

0.58 

0.68 

0.13 

TS3 

°c 

11.9 

7.6 

8.3 

1.5 

FB 

PSI 

6.3 

5.0 

5.6 

1.3 

FTIT 

°c 

18. 

13. 

13. 

13. 

PT6 

PSI 

1.2 

0.67 

0.79 

.79 

N2 

RPM 

250. 

75. 

67. 

40. 

WF 

PPH 

— 

160. 

130. 

— 

NI 

RPM 

180. 

140. 

140. 

92. 

AO 

FT2 

— 

0.54 

0.45 

— 

MACH 

— 

— 

0.15 

0.15 

— 

ALT 

FT 

— 

1100. 

1100. 

— 

PLA 

DEG 

— 

2.9 

2.3 

— 

PT2 

PSI 

— 

0.76 

0.72 

— 

T  72 

°C 

4.2 

1.8 

1.7 

1.7 

RCVV 

DEG 

EH 

1.9 

1.9 

low-power  regions.  Discussion  of  analyses  leading  to  these  conclusions  will 
now  be  presented. 

6.4  HIGH-POWER/ LOW-POWER  ANALYSES 


Scatter  plot  analyses  of  the  two  data  sets  which  were  initially 
transmitted  indicated  that  the  data  base  contained  a  large  number  of  lower 
power  points,  a  smaller  number  of  high-power  points,  and  very  few  intermediate 
power  points.  A  histogram  of  251  F100  data  points  (as  of  2/81)  by  PLA  range 
is  shown  in  Figure  6.2.  The  question  was  raised  as  to  whether  engine  data  are 
more  repeatable  at  high  power  or  low  power. 

A  methodology  for  evaluating  data  repeatability  Is  summarized  below: 

•  Engine  model: 


Y(X) 

SENSED 

-  Y(X) 

NOMINAL 

+  AEFF 

+  V  + 

W 

Observed 

True  Value 

Engine 

Sensor 

Nonrepeat 

Sensor 

of  Y  When 

Health 

Noise 

ability 

Reading 

EFF-V-W-0 

Parameter 

Noise 

•  Further  analysis  yields: 


Low-Power  Model  High-Power  Nonrepeatability 

Standard  Deviation  Standard  Deviation 


•  Larger  model  standard  deviations  Indicate  less  repeatable  data. 

Using  the  data  base,  two  subsets  were  created.  The  first  data  set 
consisted  of  valid  high-power  points  (80  <  PLA  <  90),  and  the  second  set 
consisted  of  low-power  points  (30  £  PLA  £  37).  Both  sets  represented  a 
cross-section  of  the  engines.  Variances  of  the  raw  data  and  variances  of  the 
model  residuals  were  compared  to  determine  which  data  set  was  more 
repeatable.  When  this  analysis  was  performed  Initially,  the  results  Indicated 
that  high  power  points  were  more  repeatable.  The  results  in  Table  6.8  show 
that  oLP  Is  significantly  greater  than  OyP  In  many  Instances. 

However,  the  results  were  not  entirely  conclusive  because  of  the  scarcity  of 
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Table  '.8 


data.  Changes  in  the  EDS  logic  later  in  the  program  led  to  more  high-power 
data  being  collected.  The  change  in  data  distribution  is  shown  in  Table  6.9. 

Results  of  the  la„er  analysis  are  shown  in  Tables  6.9  and  6.10.  They 
show  that  since  «^p  >  a^p  and  the  confidence  intervals  do  not  tend 
to  overlap,  high-power  data  appears  to  be  more  repeatable  than  low-power  data. 

6.5  CLUSTER  ANALYSIS 

As  mentioned  previously,  accurate  results  from  a  gas  path  analysis 
algorithm  depend  on  a  data  set  which  is  uniformly  distributed.  The  data  which 
were  analyzed  in  the  early  part  of  the  program  resided  in  clusters  which  did 
not  lend  themselves  to  accurate  model  development.  An  algorithm  was  developed 
which  provided  a  simple  and  efficient  method  for  determining  where  the 
clusters  lie.  Results  proved  to  be  useful  in  determining  whether  data  were 
uniformly  scattered,  which  points  were  outliers,  and  defining  reasonable  hard 
sensor  limits  for  data  screening. 

Operation  of  the  algorithm  is  as  follows.  The  cluster  routine  takes  as 
input  a  data  array.  First,  the  data  are  sorted  into  increasing  order.  Then 
the  average  distance  between  points  is  computed.  Points  which  are  many  times 
further  apart  than  the  average  are  discarded  as  outliers.  This  process  is 
repeated  until  no  outliers  remain. 

Finally,  the  remaining  points  are  grouped  into  clusters.  The  points  are  ' 
processed  in  increasing  order.  If  the  distance  between  points  I  and  I+l  is 
large,  point  I+l  begins  a  new  cluster.  Otherwise,  it  is  added  to  the  present 
cluster  and  the  next  point  is  processed  similarly. 

A  flowchart  illustrating  this  procedure  is  shown  in  Figure  6.3,  and 
sample  results  are  shown  in  Table  6.11. 

6.6  PILOT  OPTION/AUTOMATIC  TAKE-OFF  RECORD  ANALYSIS 

In  April  of  1981,  the  EDS  software  was  modified  to  record  automatically  a 
time  history  of  all  EDS  parameters  during  take-off.  The  data  consists  of  18 
scans  giving  the  time  history  of  a  single  take-off.  The  first  scan  is 
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TOTAL  NUMBER  OF  SCANS 


NUMBER  OF  HIGH  POWER 
SCANS  (X  OF  TOTAL) 

NUMBER  OF  HIGH  POWER 
SCANS  WITHIN  MAX  AND 
MIN  SCREENING  LIMITS 
(%  OF  TOTAL) 


Table  6.9 

ta  Acquisition  Results 

I 


DATA  BASE  THROUGH 

12  DECEMBER  1981 

DATA  BASE  SINCE 

12  DECEMBER  1981 

251 

249 

59  (23%) 

244  (94%) 

32  ( 13%) 

154  (62%) 

183 


Y 

95*  Cl 

FOR  cyLP 

95*  Cl 

FOR  oyHP 

T2SC 

(2.19,3.01) 

(1.87,2.57) 

P25C 

(.682,  .938) 

(.822,1.13) 

TS3 

(12.9,17.7) 

(3.67,5.05) 

PB 

(8.37,11.5) 

(4.65,6.40) 

FTIT 

(17.4,23.9) 

(5.90,8.12) 

PT6 

(1.00,1.38) 

(1.12,1.55) 

N2 

(109. ,150.) 

(56.1,77.2) 

WF 

(119. .164.) 

(146. ,201) 

TOTALS 

OUTLIER 


Table  6.11 

Sample  Cluster  Analysis  Results 

PILOT  OPTION  DATA,  PLA  CHANNEL  (175  POINTS) 


MINIMUM 

MAXIMUM 

-16.00 

89.31 

-16.00 

-16.00 

15.38 

17.13 

55.13 

55.81 

63.56 

89.31 

EDS  DATA,  PLA 


OUTLIER 


CHANNEL 


CLUSTER 


115.3 

582.1 

MINIMUM 

MAXIMUM 

NUMBER  OF 

15.88 

125.13 

427 

15.88 

19.56 

4 

30.06 

48.25 

166 

51.94 

93.56 

310 

104.19 

104.50 

3 

108.38 

112.94 

8 

118.44 

121.06 

4 

124.31 

125.13 

2 

recorded  4.5  seconds  before  weight  off  wheels,  and  the  Ust  scan  is  recorded 
1.0  second  after  weight  off  wheels. 

Sample  take-off  scan*,  are  shown  in  Figure  6.4.  Two  representative  plots 
are  shown  for  T25C.  In  mathematical  notation,  the  plot  shows  y(ti) 
versus  ti(i-l,2,...,18),  where 

ti  -  -  4.5,  t;>  «  -3.5,  ...»  t^g  ■  1.0 

and  y  is  T25C,  a  representative  operating  variable.  The  plot  shows  that  the 
variable  increases  approximately  linearly  during  the  5.5  seconds  in  which  it 
is  recorded. 

The  change  in  y  at  time  t^  from  Its  initial  value  y(t^)  is 
defined  as  ay(t^)  .  y(t^)  -  y(t^).  Figure  6.5  shows  plots  of 
ayU^  versus  tj(1«l,2,...,18)  for  T25C  and  represents  50  take-offs. 

The  plot  in  Figure  6.6  shows  a  statistical  summary  of  the  delta  y 
values  for  175  take-offs.  For  each  operating  variable,  there  are  three 
superimposed  plots: 

Mean  [ay(t^}]  versus  tj  (1) 

Mean  [ay(ti)j  +  Var  aylt. J  versus  t1  (2) 

Mean  [ay(t.)]  -  Var  Ay( t^ )  versus  t^  (3) 

where  the  means  and  variances  are  computed  from  the  175  take-offs.  To 
summarize.  Figure  6.6  shows  the  average  time  history  of  delta  y  and  the 
scatter  about  this  average.  This  plot  indicates  that  mean  [ay(t^)]  apears 
to  be  a  linear  function  of  tio 

Tables  6.12  and  6.13  give  standard  statistical  summaries  and  cluster 
analysis  results  for  the  EDS  data  base  (50C  points)  and  the  new  pilot  option 
data  base  (175  points).  No  data  screening  was  done  for  this  analysis. 
Comparison  of  the  standard  deviations  of  the  operating  variables  in  Tables 
6.12  and  6.13  shows  that  the  scatter  is  smaller  for  the  pilot  option  data. 
This  results  primarily  from  the  smaller  power  range  occurring  during 
take-offs. 


Figure  6.6  Delta  T25C:  Mean  and  Cl 


Table  6.12 

Statistical  Summary  of  EDS  Data  Base  (500  Points) 


CHANNEL 

NAME 

MINIMUM 

MEAN 

MAXIMUM 

STD.  DEV. 

1 

T25C 

-32.13 

170.70 

812.38 

184.38 

2 

P25C 

16.79 

31.88 

344.70 

18.14 

3 

TS3 

.03 

429.28 

726.85 

92.76 

4 

PB 

0.00 

218.85 

1689.59 

134.54 

5 

FTIT 

0.00 

774.64 

1242.25 

168.29 

6 

PT6 

-93.29 

28.47 

117.65 

10.10 

7 

N2 

0.00 

11880.93 

12873.00 

1134.15 

8 

WF 

43.45 

8807.30 

97370.29 

14729.64 

9 

N1 

0.00 

8839.85 

16102.00 

1519.14 

10 

AO 

0.00 

3.19 

6.50 

.68 

11 

MACH 

0.00 

.57 

1.22 

.25 

12 

ALT 

-2.50 

9808.01 

34622.50 

8743.07 

13 

PLA 

0.00 

67.62 

582.06 

33.46 

14 

PTC 

0.00 

12.90 

25.27 

2.69 

15 

TT2 

-15.56 

31.45 

4091.25 

183.41 

16 

RCVV 

-38.88 

-1.08 

16.00 

8.43 

191 


Table  6.13 


Several  data  sets  were  generated  to  compare  the  repeatability  of  the 
take-off  data  to  the  other  F100  data.  The  three  data  sets  are: 

1:  take-off  data  collected  at  tj  -  4.5  seconds 

2:  low-power  EDS  data  (30  £  PLA  £  40) 

3:  high-power  EDS  data  (80  <  PLA  £  90) 

All  data  sets  were  screened  for  hard  and  soft  sensor  failures,  thus  they  are 
comparable  sets  of  "clean-  data. 

The  rc-sidual  (model)  standard  deviations  for  these  data  sets  are  compared 
in  Table  6.14.  Significantly  smaller  model  standard  deviations  indicate  more 
repeatable  data.  The  low-power  data  set  appears  to  be  the  least  repeatable, 
while  the  repeatability  of  the  take-eff  and  high-powor  data  are  comparable. 
Although  the  engine  is  not  in  equilibrium  during  take-offs,  the  data  collected 
is  still  repeatable.  Hence,  the  take-off  data  appear  to  be  valuable  additions 
tn  the  data  base  and  can  be  used  for  gas  path  trending  analysis. 

5.7  FINAL  BASELINE  MODEL  DEVELOPMENT,  PARAMETERIZATION,  AND  HIGHLIGHTS  OF 

RESULTS 

Uring  d-ata  from  the  first  13  McAir  data  tapes  (for  period  of  4/16/80  tc 
5/15/81),  the  final  F100  baseline  model  was  developed.  The  data  were  screened 
according  to  the  limits  shown  in  Table  6.15.  Points  with  PLA  less  than  60 
degrees  or  greater  than  90  degrees  were  discarded.  Also  discarded  were  the 
points  with  one  or  more  sensor  failures,  as  determined  by  the  previous 
baseline  model.  The  resulting  data  set  consisted  of  112  valid  high-power  data 
scans. 

Polynomial  regression  equations  for  16  F100  operating  variables  were 
developed  using  the  MODGEN  computer  program.  Table  6.16  lists  the  independent 
variables  which  vere  chosen  for  each  of  the  equations.  Also  listed  in  Table 
6.16  are  the  resulting  model  standard  deviations. 

Figures  6.7  aM  6.8  show  selected  residual  plots  created  from  the  final 
baseline  model  and  tne  112  point  high-power  data  set.  As  with  earlier 
results,  no  marked  trends  are  discernible  from  the  residuals.  This  is  an 
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Table  6.14 


Comparison  of  Model  Standard  Deviations  Data  Set  Number 


y 

1 

2 

3 

T25C 

3.8 

2.5 

2.2 

P25C 

.74 

.79 

.95 

TS3 

5.9 

15 

4.2 

PB 

6.6 

9.7 

5.4 

FTIT 

14 

20 

6.8 

PT6 

1.2 

1.2 

1.3 

N2 

85 

130 

65 

WF 

280 

140 

170 

TAKEOFF 

LOW 

HIGH  POWER 

DATA  AT 

POWER 

EDS  DATA 

tl 

EDS 

DATA 

[#] 


ALL  BASELINE  MODELS  WERE  CHOSEN  FROM  THE 
BEST  FIT  USING  2  INDEPENDENT  VARIABLES 


Table  6. IS 


EDS  Data  Screening  Limits 


CHANNEL 

VAR 

LOWER  LIMIT 

UPPER  LIMIT 

1 

T25C 

0 

180 

2 

P25C 

14 

50 

3 

TS3 

150 

600 

4 

PB 

40 

350 

5 

FTIT 

350 

1,000 

6 

PT6 

14 

45 

7 

N2 

9000 

13,000 

8 

WF 

0 

9,000 

9 

N1 

4000 

11,000 

10 

AJ 

2.7 

5.1  . 

11 

MACH 

0 

0.9 

12 

ALT 

-1,000 

25,000 

13 

PLA 

-VARIABLE- 

14 

PT2 

5 

18 

15 

. 

-25 

60 
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Table  6.16 


F100  Baseline  Model,  June  1980 


DEPENDENT  VARIABLE 


INDEPENDENT  VARIABLES 


MODEL 

STANDARD  DEVIATION 


T25C 

P25C 

TS3 

PB 

FTIT 

PT6 

N2 

WF 

Nl 

AJ 

MACH 

ALT 

PLA 

PT2 

TT2 


Nl,AJ,TT2 

PB,AJ,RCVV,PT2*PT2 
Nl,PLA,TT2 
Nl,AJ, MACH, ALT, TT2 
Nl.PLA 

Nl , A J , P  T2 , TT2*TT2 

Nl,PLA,RCVV 

P8,N1,A0 

T25C,P8*PB,TT2*PT6 

T25C,TT2,N1*N1 

ALT.PT2 

PT2,TT2,TT2*N1 

FTIT,PT2,PB*T25C 

TT2,PE*T25C,FTIT*T25C 

T25C,RCVV,N2*FTIT 

N2,N1*FTIT 


I. 5 
0.70 

5.3 
5.9 

II. 6 
.94 
73.4 
163 
69 
.052 
.02 
2000 

2.3 
.27 

3.4 


RCVV 


1.4 


igh  Power  EDS  Data  E0694:  Residual  WF 


er  EDS  Data 


indication  that  trends  are  unlikely  to  appear  in  plots  of  the  gas  path 
parameter  estimates. 

Using  the  same  methods  as  those  applied  to  A10/TF34  TEMS  data,  EDS  fault 
parameters  were  combined  to  form  module-directed  indices.  The  resulting 
module-directed  rating  equations  are  as  follows: 

°FAN  *  °'57AnFAN  ~  0,82  aAFAN 

©COMP  *  0.56Ancoif>  —  0.59  aAqq.^  *  0.58anpc 

©Hpt  *  0.88AnHT  —  0.48  aAhj 

Figures  6.9  and  6.10  are  selected  plots  of  fan,  core,  and  net  ratings  as 
a  function  of  operating  time.  Results  in  Figure  6.9  are  not  encouraging. 
Trends  in  the  data  are  not  clearly  discernible.  The  net  rating  plot  in  figure 
6.10  shows  more  positive  results.  A  gradual  decline  in  engine  health  over 
time  can  be  seen.  Because  of  the  lack  of  maintenance  data  collected,  it  is 
not  possible  to  demonstrate  the  correlation  of  engine  health  trends  to 
maintenance  actions. 
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Figure  6.9  F100  Module-Directed  Indices 
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Figure  6.10  F100  Performance  Rating  Histories 


VII.  APPLICATION  TO  A7E/TF41  IECMS  DEPLOYMENT  DATA 


7.1  INTRODUCTION 

The  following  chapter  presents  the  results  of  SCT's  analysis  of  data 
acquired  during  the  A7E/TF41  IECMS  flight  test.  Test  background  will  be 
briefly  described  and  the  hardware  and  software  of  the  In-Flight  Engine 
Conditioning  Monitoring  System  (IECMS)  will  be  characterized.  Discussion  of 
data  analysis  and  the  application  of  the  thermodynamic  cycle  monitoring 
algorithm  will  proceed  in  vo<<r  sections: 

•  raw  data  inspection 

o  cluster  analysis  with  subsequent  additional  screening 

•  baseline  and  fault  model  developments 

•  reduction  of  fault  parameters  to  module-directed  Indices  and 
performance  algorithm  results. 

7.2  TEST  BACKGROUND 

The  data  which  were  analyzed  by  SCT  in  the  Turbine  Engine  Fault  Detection 
and  Isolation  Program  were  collected  by  the  IECMS  during  the  flight  test  phase 
of  the  IECMS  Program.  .  The  A7E  IECMS  was  deployed  aboard  the  U.S.S.  KENNEDY 
for  the  four-month  period  from  8/80  through  12/80.  Data  were  collected  for  35 
engines  which  included: 

•  40,000  frames  of  IECMS  collected  data  consisting  of  functional 
check  flight  data  and  brief  history  data  (take-off,  lift-off,  and 
trend) 

•  a  maintenance  action  file  containing  200  maintenance  actions 
issued  via  VIDS/MAF  forms 

7.3  IECMS  DESCRIPTION 

The  A7E/TF41  IECMS  Is  a  system  which  was  designed  for  the  U.S.  Navy 
attack  aircraft.  The  program  was  initiated  in  1969  with  work  done  jointly  by 
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Vought  Aircraft  and  Detroit  Diesel  Allison  to  develop  an  automated  integrated 
data  system. 

The  system  is  comprised  of  four  major  subsystems.  These  are: 
a  engine  kit 
a  avionics  kit 
a  airframe  change  kit 
a  data  processing  station 

The  engine  kit  contains  transducers,  switches,  electrical  harnesses,  and 
plumbing  necessary  to  monitor  40  engine  parameters.  Tie  avionics  kit  consists 
of  the  engine  analyzer  unit,  flag  display  unit,  and  tape  magazine  unit.  These 
components  monitor  and  signal  condition  engine  parameters,  activate  cockpit 
lights,  provide  exceedance  information  and  record  data  as  required.  The 
airframe  change  kit  includes  the  cockpit  panel,  caution  advisory  panel,  IECMS 
''nmpartment  and  wiring  harness/sensors.  This  hardware  provides  for  the 
interface  of  the  IECMS  with  the  airframe  and  engine,  ’.nd  houses  the  IECMS 
self-test  advisory  signals.  The  data  processing  station  is  ground-based  and 
consists  of  a  minicomputer,  tape  drive,  and  interface  units,  a  line  printer, 
and  a  teletype.  The  station  processes  the  in-flight  data,  outputs  diagnostic 
advisories,  and  stores  the  data  on  a  magnetic  tape  for  further  processing  at 
the  central  computer  facility. 

The  IECMS  hardware  continuously  monitors  engine  parameters,  while  the 
software  determines  operational  modes  and  the  need  for  recording  data.  Data 
are  collected  during  the  following  operational  conditions  [48,49]: 

•  engine  exceedance 

•  marked  rate  of  change  in  NH,  PLA,  or  T5 

•  normal  recording  mode  (single  frame  recording  -  5.6  seconds  of 

data) 

-  start 

-  ground  idle 

-  take-off 

-  vibration 

-  cruise 

-  end  of  flight 
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Diagnostic  Indicators  on  the  flag  display  unit  provide  a  go/no-go  message. 

Data  which  are  collected  on  the  airframe  can  be  transferred  to  the 
ground-based  data  processing  station  via  tape  transcription.  Ground-based 
processing  yields  diagnostic  summaries  for  each  flight,  documentary  data  and 
diagnostic  information  related  to  the  flight. 

7.4  DATA  INSPECTION 

Before  analyzing  the  data,  plots  of  raw  data  were  made  for  several 
engines  for  the  purpose  of  visual  Inspection.  The  plots  reveal  the  character 
of  the  data  and  bring  to  light  some  anomalies  which  must  be  borne  in  mind  when 
evaluating  the  application  of  the  thermodynamic  cycle  monitoring  algorithm  to 
the  data. 

The  unstable  character  of  the  IECMS  take-off  data  frames  indicated  that 
these  data  would  not  be  suitable  for  processing  by  the  thermodynamic  cycle 
monitoring  algorithm.  This  relatively  small  amount  of  data  was  therefore  not 
included  in  the  subsequent  processing.  Upon  transfer  to  the  MIMS,  vibration 
data  were  labelled  as  mode  2000  for  Identification  purposes.  Since  these  data 
are  typically  recorded  within  a  few  hundred  feet  after  take-off,  the  IECMS 
vibration  data  will  hereafter  be  referred  to  as  take-off  data  or  mode  2000 
data.  Cruise  data  were  labelled  as  mode  4000  data. 

Figures 7.1  through  7,3  show  Julian  date  plotted  as  a  function  of  total 
operating  time.  They  reveal  that  for  the  engines  shown,  one  of  the  two 
variables  or  both  were  incorrectly  recorded.  Because  the  thermodynamic  cycle 
monitoring  algorithm  is  designed  to  predict  ermine  health  as  a  function  of 
operating  time,  its  successful  application  to  these  data  is  hindered.  These 
inconsistencies  also  make  it  Impossible  to  arrive  at  meaningful  conclusions 
when  correlating  engine  health  trends  with  maintenance  action  data. 

7.5  CLUSTER  ANALYSIS  AND  DATA  SCREENING 


As  described  in  Section  7.3,  IECMS  data  are  normally  recorded  during  six 
predefined  modes  of  engine  operation.  Data  are  collectively  written  to  e 
single  file  where  the  data  types  are  identified  in  the  respective  data 
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Figure  7.2  E2553  Takeoff  I 


records.  Data  were  sorted  according  to  recording  mor  und  three  subsets  of 
data  were  created;  cruise  data,  take-off  data,  and  a  combined  set  of  data. 
Grouping  of  data  in  this  fashion  allows  for  a  more  uniform  distribution  of 
points,  making  it  amenable  to  input  to  the  thermodynamic  cycle  monitoring 
algorithm. 

The  cluster  analysis  program  which  was  described  in  Chapter  VI  was 
executed  on  these  data  sets  and  used  to  define  data  screening  limits.  For 
each  data  set,  maximum  and  minimum  values  were  found  for  each  of  17  channels. 
These  v*  ues  are  listed  in  Table  7.1.  Additionally,  the  data  were  plotted  to 
allow  for  visual  inspection  of  the  data  distribution.  Figures  7.4  through  7.6 
illustrate  the  clustering  of  data  according  to  operational  mode.  With  this 
Information,  suitable  margins  were  added/subtracted  from  the  maximum  and 
minimum  values.  Table  7.2  lists  the  screening  limits  which  were  finally 
applied  to  the  cruise  and  take-off  data  sets.  Of  the  1988  points  originally 
in  the  take-cff  data  set,  and  the  2149  points  In  the  cruise  data  set,  1660  and 
1537  points  remained  in  each  of  these  sets,  respective iys  subsequent  to 
screening.  This  screening  process  eliminates  data  scans  with  hard  sensor 
failures.  Only  20  percent  of  the  frames  are  rejected  by  this  process, 
indicating  that  deficiencies  in  the  data  due  to  hard  sensor  failures  were 
minor. 

7.6  BASELINE  AND  FAULT  MODEL  DEVELOPMENT 

Baseline  engine  models  were  created  for  each  of  the  two  data  sets  for  12 
variables.  Table  7.3  provides  a  statistical  summary  of  the  model  accuracies. 
The  smaller  standard  deviations  seen  In  the  take-off  data  support  the 
conclusion*  pi  rented  in  Chipter  VI  that  take-off  mode  data  are  more 
repeatable  the  cruise  mode  data. 

Residual  plots  of  engine  variables  which  were  made  during  baseline  model 
development  provide  an  indication  of  the  applicability  of  the  thermodynamic 
cycle  monitoring  algorithm  to  IECMS  data.  Figures  7.7  through  7.9  Illustrate 
the  dynamic  characteristics  of  the  data.  IECMS  data  were  grouped  into  5-hour 
windows  for  trending  purposes.  The  resulting  data  consisted  of  roughtly  1  to 
11  trend  points  per  engine  over  200  hours  of  total  operating  time.  Plots  of 
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Table  7.1 

Maximum  and  Minimum  Values  of  Data  Sets 


CRUISE  MODE  DATA 


NUMBER 

OF  POINTS 

2149 

CHANNEL 

MINIMUM 

MAXIMUM 

lltl 


3 

T3 

-482.72 

4 

T5 

-627.20 

5 

PT51 

-0.58651 

6 

WF 

O.OOOOOE+OO 

7 

NH 

7.4715 

8 

NL 

7.3814 

9 

ALT 

-1000.0 

10 

MACH 

O.OOOOOE+OO 

11 

PLA 

-6.0044 

12 

OAT 

-56.406 

13 

T1 

-76.904 

14 

IGV 

-109.74 

15 

TOT 

0.69008 

16 

MODE 

4000.0 

17 

JULI 

80013. 

130.00 
376.60 
839.55 
584.41 
50.000 
34130. 
1510.2 
138.25 
0.24718E+06 
9.8958 

335.67 
96.909 
75.640 

139.68 
1077.5 
4000.0 
81354 


Table  7.1  (Continued) 


TAKE-OFF  MODE  DATA 


NUMBER  OF  POINTS  1988 

CHANNEL  MINIMUM  MAXIMUM 


1 

PHMG 

-130.13 

130.00 

2 

PS3 

-218.12 

294.77 

3 

T3 

-341.54 

738.15 

4 

T5 

-464.78 

623.47 

5 

PT51 

12.317 

50.000 

6 

WF 

54.056 

23363. 

7 

NH 

25.297 

3022.7 

8 

NL 

26.353 

421.78 

9 

ALT 

-1000.0 

0.24712E+06 

10 

MACH 

0.53768E-01 

2.5002 

11 

PLA 

-1.1270 

350.08 

12 

OAT 

-56.213 

148.27 

13 

T1 

8.2004 

48.131 

14 

IGV 

-117.80 

121.24 

15 

TOT 

0.29507E-01 

1077.2 

16 

MODE 

2000.0 

2000.0 

17 

JULI 

80013. 

81354. 

CRUISE  AND  TAKE-OFF  MODE  DATA 


NUMBER 

CHANNEL 

OF  POINTS 

MINIMUM 

4137 

MAXIMUM 

PHMG 

-130.13 

130.00 

-218.12 

376.60 

3 

T3 

-482.72 

839.55 

4 

T5 

-627.20 

623.47 

5 

PT5J. 

-0.58651 

50.000 

6 

WF 

O.OOOOOE+OO 

34130. 

7 

NH 

7.4715 

3022.7 

8 

NL 

7.3824 

421.78 

9 

ALT 

-1000.00 

0.24718E+06 

10 

MACH 

O.OOOOOE+OO 

9.8958 

11 

PLA 

-6.0044 

350.08 

12 

OAT 

-56.406 

148.27 

13 

T1 

-76.904 

75.640 

14 

IGU 

-117.80 

139.68 

15 

TOT 

0.29507E-01 

1077.5 

16 

MODE 

2000.0 

4000.0 

.17 

JULI 

80013. 

81354. 

Figure  7.5  Cruise  Data  Distribution  Plot 


Combined  Data  Set  Distribution  Plot 


Table  7.2 

IECMS  Data  Screening  Limits 


TAKE-OFF  MODE 

CRUISE  MODE 

LOW 

HIGH 

LOW 

HIGH 

200 

280 

100 

250 

mM 

350 

500 

350 

500 

T5 

500 

650 

500 

600 

PT51 

25 

45 

10 

40 

WF 

5,000 

13,000 

5,000 

10,000 

NL 

80 

100 

80 

100 

NH 

80 

100 

80 

110 

ALT 

-1000 

50,000 

-1000 

50,000 

MACH 

.01 

.95 

.01 

.95 

PLA 

5 

95 

5 

95 

OAT 

-25 

140 

-25 

140 

T1 

-10 

100 

-10 

100 
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Table  7.3 

IECMS  Baseline  Model  Statistical  Summaries 


E25S3 :  RESIDUAL  PS3  (MQDE=2669,  NFTS=156) 


Data 


Figure  7.9  IECMS  Cruise  Data  (E1226) 


these  date  show  large  gaps  In  the  data  which  impede  trending.  What  appeared 
initially  to  be  a  voluminous  set  of  data  actually  amounts  to  a  smaller  set  of 
data  (on  a  per-engine  basis)  collected  at  irregular  intervals  (see  Figure 
7.9).  Experience  witii  TEMS  and  EDS  data  showed  that  for  trending  purposes,  it 
would  be  more  desirable  to  have  one  to  two  repeatable  data  points  per  flight 
(per  engine). 

The  residual  plots  also  give  an  indication  of  the  accuracy  of  the 
baseline  model.  Points  plotted  in  Figures  7.7  and  7.8  show  that  the  points 
are  scattered  around  zero,  an  indication  of  the  correctness  of  the  models. 

The  plots  also  provide  further  evidence  that  take-off  data  is  more  repeatable 
than  cruise  data.  Figures  7.7  and  7.8  show  that  the  residual  FS3  for  engine 
2553  is  more  closely  scattered  about  zero  for  take-off  mode  data  than  for 
cruise  mode  data. 

Using  a  procedure  similar  to  that  used  in  developing  baseline  models, 
fault  models  were  extracted  from  TF41  status  deck  data.  The  data  base  used 
for  this  purpose  was  created  by  executing  the  status  deck  over  a  range  of 
flight  conditions.  For  each  set  of  flight  conditions,  the  program  was 
executed  while  varying  engine  component  efficiencies  and  flow  areas  (i.e. 
fault  parameters).  Table  7.4  lists  the  flight  conditions  chosen  for  this 
purpose.  The  values  were  chosen  to  be  compatible  with  the  flight  conditions 
of  the  in-flight  engine  data,  and  consistent  with  variations  In  efficiencies 
and  areas  whidh  characterize  the  engine  design.  A  list  which  defines  the 
efficiencies  and  areas  and  the  percent  deviations  of  these  variables  is 
provided  in  Table  7.5. 

7.7  MODULE-DIRECTED  RATING  PARAMETERS/ PERFORMANCE  ALGORITHM  RESULTS 

By  taking  linear  combinations  of  engine  fault  parameters,  three 
module-directed  indices  were  created  for  the  IECMS.  The  ratings  correspond  to 
the  low-spool,  high-pass  turbine  and  compressor  sections  of  the  engine.  A  net 
rating  corresponds  to  the  average  of  these  three  parameters.  Trend  plots  of 
the  ratings  as  a  function  of  time  are  subject  to  interpretation.  There  are, 
however,  a  few  conclusions  which  can  be  made  with  some  degree  of  certainty. 


Table  7.5 

Fault  Parameter  Definitions  and  Perturbations 


Anc 

CORE  EFFICIENCY  DELTA 

.97,  .99,  1.0,  1.01,  1.03 

Anp 

FAN  EFFICIENCY  DELTA 

i' 

atiht 

HISH  PASS  TURBINE  EFFICIENCY 
DELTA 

Ai>LT 

LOW  PASS  TURBINE  EFFICIENCY 

DELTA 

aAc 

CORE  AREA  DELTA 

.95,  .97,  1.0,  1.03,  1.05 

AAp 

FAN  AREA  DELTA 

aAhT 

HIGH  PASS  TURBINE 

aAlt 

LOW  PASS  TURBINE  AREA  DELTA 

Sample  results  are  presented  in  Figures  7.10  through  7.15.  A  plot  of 
residual  T3  for  engine  2553  (Figure  7.10)  shows  a  marked  jump  at  125  operating 
hours.  This  jump  Is  correlated  with  a  jump  in  engine  vibration  in  Figure 
7.11.  It  is  conceivable  that  increased  vibration  affected  the  T3  sensor  to 
produce  the  jump  in  the  temperature  readings. 

Figures  7.12  and  7.13  show  the  low-spool  rating  (©^)  and  compressor 
rating  (©2)  for  engine  1930  plotted  as  a  function  of  engine  operating 
time.  These  plots  show  declining  ratings  over  time  with  jumps  which  may 
correspond  to  engine  maintenance  actions.  However,  the  lack  of  maintenance 
data  together  with  gaps  in  the  data  prevent  firm  conclusions  from  being  drawn. 

Also  shown  in  Figures  7.12  and  7.13  are  the  uncertainty  bands  around  each 
parameter  estimate.  These  bands  indicate  the  degree  of  confidence  In  each 
parameter  estimate.  One  factor  in  determining  these  bands  are  the  number  of 
original  data  points  in  the  5-hour  window.  The  large  uncertainty  in  the 
estimate  of  ©!  at  120  hours  (Figure  7.13)  is  caused  by  having  only  two 
data  points  in  the  window  (see  Figure  7.14).  As  the  number  of  points  within 
each  window  increases,  the  uncertainty  in  the  parameter  estimates  decreases. 

Figure  7.15  shows  a  low-spool  parameter  plot  for  engine  2553.  Here  also, 
short-term  declines  in  the  parameter  are  shown.  Improvements  in  the  module 
health  rating  at  170  hours  and  300  hours  may  be  due  to  maintenance  actions. 

The  gap  in  the  data  between  280  and  340  hours  prevents  the  ;act  time  of  the 
jump  from  being  determined. 

Most  of  the  plots  lend  evidence  supporting  the  conclusion  that  take-off 
data  are  more  amenable  to  trending  algorithms  than  cruise  data.  An 
illustration  of  this  is  shown  in  Figures  7.16  through  7.19,  where  health 
parameters  and  corresponding  confidence  intervals  are  plotted  for  engines  1333 
and  1243.  These  plots  show  that  the  confidence  intervals  are  much  smaller  for 
the  take-off  data.  The  question  remains  to  be  determined,  however,  whether 
this  increased  certainty  in  the  parameter  estimates  is  due  to  the  number  of 
data  points  used  in  calculating  the  estimate,  or  to  the  correlation  of 
parameter  residuals. 
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Figure  7.11  Vibration  History  for  E2553 


12  Low  Spool  Ra 
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Figure  7.13  Compress 
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Figure  7.18  Low  Spool  Rating  -  Cruise  Mode  Data 


ENGSN  1243,  MODE  2OO0,  IECMS  DBTfi 


VIII.  SUMMARY  AND  CONCLUSIONS 


This  report  has  addressed  the  problem  of  reducing  engine  monitoring  data 
to  usable  performance  parameters  and  integrating  these  data  Into  the  Air  Force 
maintenance/logistics  organization  to  support  engine  management.  The  engine 
performance  monitoring  problem  was  introduced  in  Chapter  II  and  then  a 
mathematical  solution  to  the  problem  was  presented  in  Chapter  III.  The  method 
developed  in  Chapter  III,  the  thermodynamic  cycle  monitoring  algorithm, 
demonstrates  that  it  is  theoretically  possible  to  derive  quantitative  health 
indices  from  engine  monitoring  data. 

The  thermodynamic  cycle  monitoring  (TCM)  algorithm  Is  based  on  state  of 
the  art  techniques  in  statistical  regression  analysis  and  nonlinear  estimation 
theory.  Included  in  this  general  methodology  are  completely  new  and  extremely 
promising  sensor  validation  and  trending  routines.  The  mathematical  methods 
developed  in  Chapter  III  have  been  implemented  as  a  set  of  flexible  and 
efficient  software  modules.  The  results  of  the  TCM  algorithm  as  applied  to 
TF34/TEMS,  FIOO/EIK,  and  TF41/IECMS  data  bases  are  presented  in  Chapters  V 
through  VII,  respectively.  Results  of  Chapter  V  indicate  that  it  is 
practically  feasible  to  derive  engine/module  health  indices  from  engine 
monitoring  data  and  to  correlate  the  results  with  engine  maintenance  actions. 
The  successful  detection  and  Isolation  of  failed  sensors  is  also 
demonstrated.  The  results  in  Chapters  VI  and  VII  are  mixed,  yet  valuable 
Insights  are  gained  into  the  data  collection  requirements  necessary  for 
successful  implementation  of  the  TCM  algorithm. 

The  requirements  for  Integration  of  performance  monitoring  Into  the  Air 
Force  engine  management  process  were  presented  in  Chapter  IV.  Implicit  in  the 
requirements  identified  by  this  study  is  t*,e  general  concept  for  a  Maintenance 
Information  Management  System  (MIMS).  The  MIMS  is  a  vehicle  for  integrating 
performance  diagnostics  and  automatically  acquired  data  Into  existing 
information  flow,  and  facilitating  user  access  of  summary  an<i  trend 
information.  Data  management  architecture,  information  flow,  and 
hardware /software  integration  aspects  are  the  fundamental  elements  of  the 
requirements  definition. 
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Using  the  Phase  I  study  results  and  methodology  presented  in  Chapters  II 
and  III,  SCT  de  eloped  software  to  support  the  maintenance  information 
management  system.  This  included  development  of  applications  software,  a 
specialized  data  manager,  and  graphics  terminals/display  drivers.  The 
software  architecture  includes  sequential  acquisition/qualification  of  data, 
efficient  user  interface,  multi-indexed  query  capability,  and  multimedia  data 
transfer  and  output.  In  short,  the  MIMS  links  local  data  collection  and 
processing  for  maintenance  decisions  with  centralized  historical  data 
preservation  and  analysis  for  logistical  decisions. 
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